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The latest buzzword penetrating the professional computer 
science literature 1s Object-Oriented Programming. Computer 
scientists extol its theoretical virtues while developers 
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development. Amidst all this activity there remains 
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concepts. Too often, students of object-oriented programming 
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conflicting, efforts at exploiting reusability, information 
hiding and other object-oriented capabilities. 

This thesis reviews the benefits attributed to object- 
oriented programming, arrives at definitions for fundamental 
concepts, advances recommendations for conducting object- 
oriented analysis and object-oriented design, and reviews 
some tradeoffs which designers need to consider when 


developing object-oriented classes and hierarchies. 
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1 INTRODUCTION 


Acolytes Oe object-oriented (OO) concepts and 
methodologies maintain that this new approach to software 
development promises to be more than just another set of 
programming languages. Rather, it represents a comprehensive 
philosophy for planning, designing, and implementing solutions 
to complex problems. An explosion of articles, magazines, 
books, and conferences dedicated to exploring and popularizing 
OO techniques occurred during the 1980’s. This concentration 
of effort notwithstanding, the OO philosophy has yet to arrive 
at a consolidated point-of-view on many fundamental concepts. 

The objective of this thesis is to review the potential 
benefits of OO techniques, to define fundamental OO concepts, 
to advance recommendations for organizing OO design, and to 
demonstrate conflicts among OO mechanisms that dilute the 
favorable properties ascribed to object-oriented programming 
HOOP) . 

The beneficial properties of the OO approach to software 
development are briefly reviewed in this chapter. These 
properties are commonly viewed as desirable from the 
perspective of software engineering. Not all the properties 
are unique to the OO philosophy, much less common to all 
object-oriented programming languages (OOPLs). Nevertheless, 


il 


the OO philosophy represents a comprehensive attempt at 
integrating all the concepts and facilities affecting the 
software lifecycle in a fashion that enhances the desirable 
properties. 
A. COMPLEXITY MANAGEMENT 
Software development increasingly occurs in an industrial 
setting typified by product complexity, system longevity, and 
incessant product evolution. (Jacobson, 1991) OO techniques 
have been employed for developing complex software products 
Such as compilers, databases, computer aided design (CAD) 
systems, Simulations, meta models, operating systems, 
spreadsheets, Signal processors, and control systems. 
(Rumbaugh, 1991) Development of such complex systems requires 
architectures, methods, and processes that divide system 
development into smaller parts and that can handle change 
efficiently. (Jacobson, 1991) The following subsections list 
desirable software features which the OO approach to software 
development attempts to innovate, thus making it well suited 
for managing complex application problems. 
1. Abstraction 
Abstraction is used to simplify the design of a 
complex system by reducing the number of details that 
must be considered at the same time. (Berzins, 1991, 
Pg- 79) 
Abstraction is an intellectual process that 


facilitates the comprehension of complex entities and 


processes through simplification. This simplification allows 
knowledge to be expressed as generalized, essential 
information which can be absorbed and understood by human 
beings. 

The level of detail necessary to formulate an 
abstraction varies with the requirements of the problem. 
(Booch, 1987) In the context of OO analysis, design, and 
programming, abstraction focuses attention on the behaviors 
and attributes of objects rather than on the implementation 
details (which vary from one language to another). This 
method of thinking about problem entities allows problems to 
be pursued as successive refinements, with each refinement 
constituting an abstraction manifesting a particular level of 
detail. Hence, designs and programs can be conceived of as 
multileveled structures of abstractions. 

2. Information Hiding 
Information hiding emphasizes the need to separate 
function from implementation. Apart from continuity, 
it ais also related to the requirements’ of 
decomposability, composability and understandability: 
to separately develop the modules of a system, to 
combine various existing modules, or to understand 
individual modules, it is indispensable to know what 
each of them may and may not expect from the others. 
(Meyer, 1988, pg. 23) 


Information hiding’ is a technique for minimizing 


interdependencies among separately written modules. (Snyder, 


*Sometimes termed encapsulation in the OO literature. 
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1986) Knowledge about data structure and function 
implementation is kept private by forcing interaction with 
these structures through an external interface. In the wider 
context of software development, information hiding promotes 
the independent construction of cooperating modules, and, most 
importantly, isolates the effects On implementation 
modification to the affected module. So long as external 
interfaces are stable, implementation details can be modified 
without impinging upon users of the interface. Hence, 
software maintenance becomes localized, no longer a perilous 
search for linkages in interrelated program modules, with 
consequent economies in time, human, and onetary resources. 

Information hiding is a critical metric of any OOPL. 
Consequently, individual OOPLs should be studied to determine 
the degree to which information hiding is enforced. 

3. Reusability 
Reuse may be defined as the effective ability to 
incorporate objects created for one software system 
into a different software system. The essence of 
reuse is the ability to take all or part of a product 
and completely and correctly embed it within a new 
product that may be constituted and structured quite 

differently. (Wasserman, 1991, pg. 55) 

Reusability clearly coincides with ‘why reinvent the 
wheel’ modes of thinking. Even limited software development 
experience 18 enough for one to notice that programs exhibit 
pervasive commonalities with respect to algorithms, data 


structures, and functions. Reusability is a language property 
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that allows previously developed software to be readily 
incorporated into new software. Two substantial benefits flow 
from reuse: (1) development effort is reduced; and, (2) reused 
code has (presumably) been tested and verified’. 

The principal OO mechanisms for achieving reuse are 
inheritance, polymorphism, and dynamic binding. Much of the 
value of programming in the OO environment arises from the 
Capability to use previously developed code stored in software 
libraries. Developers may also be familiar with a problem’s 
requirements and important abstractions; consequently, 
opportunities for reusing not only software, but entire 
designs and requirements also exist. (Booch, 1991) 

4. Extendibility 

Extendibility is the ease with which software products 

may be adapted to changes in requirements. (Meyer, 

ISG, DG. 2) 

Peenad totiity 1c Ta 'eoncept allied to, but distinct 
from, reusability. It encompasses those properties/mechanisms 
which enable new code to be developed as extensions to 
previously written code. Extendibility assumes’ greater 
importance as problem understanding improves, resulting in new 
requirements. As program scale grows, extendibility is best 


achieved through design sjaliqyellarebties, and modular 


*This does not, however, relieve developers of the burden 
of ensuring that borrowed code still functions properly in its 
new environment. (Perry, 1990) 
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decentralization. (Meyer, 1988) In the OO environment, 
extendibility is realized through the application of 
inheritance techniques to class definitions in class 
hierarchies. 
5. Maintainability 

A designer endeavors to organize a design so that it 

is resilient to change; a packaging that will remain 

stable over time is sought. The answer is to separate 

those parts of the system that are intrinsically 

volatile from those parts that are likely to be 

stable. (Coad and Yourdon, tJ lpo 17 

Maintainability is principally an economic concept. 
It refers to the efficiency by which modifications can be 
introduced over the software lifecycle. Technically, 
maintainability concerns the degree to which linkages in 
program elements eenee the effects of modifications. 
Economically, maintainability reflects the cost required to 
correct bugs, to modify code, or to extend code. The primary 
cost is the human effort required to police change. Software 
which collectively exhibits strong abstraction, information 
hiding, reusability, and extendibility generally manifest 
favorable maintainability properties. 
B. THESIS MOTIVATION 

In point of fact, the lack of a standardized conceptual 

foundation for many OO ideas has resulted in an uneven record 


with respect to the completeness with which individual OOPLs 


contribute toward achieving a unified realization of the 


beneficial software properties. One of the purposes of this 
thesis is to indicate the mapping of fundamental OO concepts 
to abstraction, information hiding, reusability, 
extendibility, and maintainability. Given these associations, 
it is possible to investigate how the interactions of language 
mechanisms which engineer the fundamental OO concepts can 
mitigate the desirable properties should potential conflicts 
not be thoroughly understood. A primary objective, therefore, 
is to facilitate better OO software development by 
acknowledging that conflicts exist which must be accounted for 
during analysis, design, implementation, and maintenance. 
C. THESIS ORGANIZATION 

Chapter II surveys the OO literature in attempting to 
formulate definitions for fundamental OO concepts. Chapter 
TII draws upon the OO literature to advance recommendations 
for conducting object-oriented analysis (OOA) and object- 
oriented design (OOD). Chapter IV examines connections 
between functional decomposition and subclass responsibility. 
Chapter V furthers the aims of Chapter III by investigating 
two mayor OO problems: (1) conflicts between information 
hiding and inheritance mechanisms; and, (2) design conflicts 
between composition and inheritance. Finally, Chapter VI 


emerers Conclusions and suggestions for further research. 


II. FUNDAMENTAL OBJECT-ORIENTED CONCEPTS 


OO methodology is occasionally presented as a Kuhnian 
paradigm by which is meant a corpus of scientific work which 
".,.defines the legitimate problems and methods of a research 
field for succeeding generations of practitioners." (Kuhn, 
1962, pg. 10) Budd accepts this departure point, adding that 
the OO paradigm "...forces us to reconsider our thinking about 
computation, about what it means to perform computation, about 
how information should be structured within a computer." 
(Budd, 199) eo a) Essentially, then, the OO paradigm is 
about knowledge representation in the computer environment. 
From this perspective, OO methodology constitutes a new way of 
conceptualizing and solving the problems of software 
engineering. 

Although there currently exist no OO standards for 00 
language designers to observe, considerable consensus exists 
as to the primary concepts which formulate the OO paradigm. 
Nevertheless, there remains sufficient semantic variation in 
the literature to warrant a thorough review of these concepts. 
The balance of this chapter surveys the OO literature with the 
intent of arriving at definitions of fundamental concepts for 


use in succeeding chapters. 


A. OBJECTS 

Objects occupy a curious dual status. Often, they are 
introduced in anthropomorphic terms as the entities (physical 
or ideational) in the problem domain. Alternatively, they are 
presented as the primary programming constructs in 00 
languages; constructs which '’closely’ parallel the entities in 
the problem domain. Although the differences between the two 
views are minimal in terms of practical consequences for OO 
analysis and design, the distinction should be bourn in mind 
Since the latter emphasizes that objects are constrained not 
only by their real-world possibilities but also by the 
Capabilities of computers and programming languages. 

1. Definition 


Objects encapsulate both state and behavior. (Halbert 
anagee sBr1len loo], pqs 72) 


Objects are entities that combine the properties of 
procedures and data since they perform computations 
and save local state. (Stefik and Bobrow, 1986,pg. 41) 
An object has state, behavior, and identity; the 
structure and behavior of similar objects are defined 
by their common characteristics; the terms instance 
and object are interchangeable. (Booch,1991, pg. 77) 
Objects are autonomous entities that respond to 
messages OF operations and share a state. 
Wegner oe Od. 163) 
Several salient points can be drawn from these 
definitions. First, objects have a structure (representation), 
which preserves the state of an object. An object may 


manifest many states over the course of its existence (i.e., 
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its state may change); hence, objects can have a history. 
Second, objects exhibit observable behavior. Objects 
communicate with one another by passing messages to elicit 
needed behavior’. Third, objects have, in some sense, an 
existential status that uniquely distinguishes each object 
from all others. This status is usually termed identity. 
Fourth, the fact that an object has an identity and can have 
a history implies that it can exist beyond the lifetime of the 
program(s) in which the object may have been created or used. 
This quality is termed persistence. (Loomis, 1991) 

A few clarifications are in order. Objects can be 
created that do not have ae structure However, it is 
difficult to isolate what-distinguishes these entities from 
procedures, and calls into question the existential status of 
such entities - that is, must not there be a ’some’ for an 
object to be something? Behavior is the set of actions an 
object can undertake. In the context of a program, an object 


sends a message to another object (or itself) requesting a 


‘Message-passing is one mechanism for managing object 


communication. Messages are sent "...to an object to tell it 
to perform one of its methods." (Nelson, 1991, pg. 4) 
Messages are essentially legal invocations of methods 
(behaviors) associated with objects. Legal invocations are 


those made to methods which objects have made available. Note 
that not every OOPL utilizes message-passing as the mechanism 


for inter-object communication. CLOS (Keene, 1989), for 
example, uses generic function calls. This sometimes leads to 
what 1s called the "message passing paradigm" in which "...the 


only way to access an object or any of its variables is by 
sending it a message." (Nelson, 1991, pg. 4) 
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service offered by the receiving object. The receiving object 
determines how best to comply with the request, selecting 
among a set of methods (operations) which satisfy the request, 
responding in a form that the sender can understand and use. 
Hence, there is a semantic quality to behavior. Note that 
much of the versatility and confusion in OO programming arises 
from the mechanisms that determine which object receives a 
request and which method is selected. 
2. Identity 

As stated in the introduction to this chapter, the OO 
paradigm constitutes a new approach to representing knowledge 
in the computer environment. Specifically, objects, as 
programming constructs, achieve a sufficiently elevated level 
of abstraction so as to closely parallel their real-world 
counterparts. Real-world entities are bounded = and 
distinguishable. In the computer environment this requires 
"...the ability to distinguish objects from one another 
regardless of their content, location or addressability, and 
to be able to share objects. Object identity enables us to 
realize this goal." (Khoshafian and Copeland, 1986, pg. 
406) 

The practical consequence is that an OO language 
should preserve this existential status as an independent fact 
about objects. This existential status can be described as 
the space (which is relocatable) in any memory which the 


Jol 


object happens to occupy. It can be argued that an OO 
language must maintain identity despite changes in an object’s 
state, address, or user-defined name, and throughout its 
lifetime. (Khoshafian and Copeland, 1986) An OO language 
accomplishes this best by maintaining a built-in identifier 
for an object that (presumably) does not change. "The failure 
to recognize the difference between the name of an object and 
the object itself is the source of many kinds of errors in 
object-oriented programming." (Booch, 1991, pg. 84) These 
errors include assignment operations which orphan objects’, 
aliasing through assignment (structural “sharing, and 
inappropriate semantics for equality operators. (Booch, 1991) 
3. Persistence 

An object is created, persists for some period of 
time, and can be destroyed. Its lifetime may be less than, 
parallel to, or exceed that of the program in which it is 
created. This last possibility represents a database issue in 
general, but with particular refinements for objects; the 
identity and nature (class of which it is an instance) of an 


object must be preserved along with its state. 


‘For example, the assignment object _x := object _y renders 
inaccessible the original object for which object_x was the 
name. 
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4. Conceptual Distinctions 
a. Objects and Programs 
The OO paradigm leads the programmer to an 
entirely different perspective on program construction. What 
has been described as the traditional imperative approach to 
programming consists of procedural modules which act on data. 
This perspective leads to a top-down, functional decomposition 
er. programs. OO programs consist of objects acting 
cooperatively, but autonomously. Cooperative behavior can 
achieve various levels of integration, producing system 
behavior at the highest levels. The great strength of this 
approach is the comparative ease with which complex systems 
can be modeled as interacting objects. 
b. Objects and Data 
Objects are not simply data structures. flys alte! 
important to recognize that objects are entities which 
manifest both structure and behavior. Moreover, the 
implementation of an object’s structure should be hidden from 
other objects (1.e., encapsulated) for the reasons outlined in 
Chapter I. This is not the case for data driven programs in 
which data structures are globally accessed and modified. 
c. Objects and Equality 
Object identity necessitates reviewing in what 
respect objects can be said to be equal. Database 
applications may require that relational comparisons be 
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available. (Nelson, Moshell, and Orooji, 1990) Most OO 
languages allow programmers to generate operations for 
determining equality. Variations include reference identity 
in which references point to the same object, and structural 
identity in which corresponding parts of objects have theysame 
value. It is worth noting that the semantics of equality and 
relational operators in this context do not necessarily follow 
the use of normal logic - objects can at once be not greater 
than, not equal to, and not less than one another’. (Nelson, 
Moshel PT, wand Oreo ji, oe 
B. CLASSES 

A major milestone in the evolution of software engineering 
has been the modularization of software components. Berzins 
and Lugi define a module as a "...conceptual unit in a 
software system that corresponds to a Ne velies identifiable 
region of the program text." (Berzins and Lugqi, 1991, pg. 13) 


From this perspective, modularization is a facet of software 


construction which produces "...software systems made of 
autonomous elements connected by a coherent, simple 
structure." (Meyer, 1988, pg. 11) 


Actual modular elements will vary among programming 
languages; the essential aspect of modularization is that it 
*"Nelson, Moshell, and Orooji suggest that there are 
contexts in which "...it 1s inappropriate to say that one 
object is greater than or less than another." (Nelson, 


Moshell, =and VOreo ja, 19907. pee se) 
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promotes conceptual localization of code. This localization 
can be exploited to realize other desirable software 
properties including data abstraction, encapsulation, 
reusability, extendibility, reliability, and maintainability. 
Classes are the key modules in most OO languages. Note 
that this position is taken in view of the fact that objects 
are declared as instances of classes. It is perhaps more 
accurate to state that classes are the key design modules and 
objects, as instances of classes, are the key program modules. 
Most OO languages provide for classes, although a few do 
mot. The various languages utilizing classes do so for 
different purposes, depending upon their overall philosophy. 
This section surveys the differing uses for classes. 
1. Definition 
A class is a template (cookie cutter) from which 
objects may be created by ‘create’ or ‘/new’ 
operations. Objects of the same class have common 
operations and therefore uniform behavior. (Wegner, 
Poo pg. 169) 
A class is a description of one or more similar 
objects. In comparison to procedural programming 
languages, classes correspond to types. (Stefik and 
BOljmOW,. 19060, pq. 42) 
Whereas an object is a concrete entity that exists in 
time and = space, a class represents Cnty an 
abstraction, the ’essence’ of an object, as it were. 
(BOCeCh ero, pg. .~93) 
A class should allow you to build a taxonomy of 


objects on an abstract, conceptual level. (Wirfs- 
Brock, Wilkersem, and Wiener, 1990, pg. 22) 
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An object manifests structure and behavior. Groups of 
objects may display common structure and behaviors which can 
be abstracted into class definitions’. Once an object is 
identified (declared) as belonging to a particular class, its 
structure and behavior can be delimited according to that 
common definition. This contributes powerfully toward 
reusability: individual objects acquire definition from an 
existing class ‘template’. 

A class typically consists of variables whose values 
are either defined individually for each object (instance 
variables), or are defined in the class definition itself as 
belonging to all instances (class variab ¢s), and of methods 
which define behavior appropriate to instances of the class. 
Some of the methods ina class are auxiliary in the sense that 
they carry out operations needed by other methods, but do not 


themselves correspond to abstractions which are observable. 


‘Odell presents a philosophical analysis of classes that 
begins with describing cognitive categories for discussing 
knowledge and knowledge acquisition. (Odell, 1991) His 
principle point is that humans formulate their understanding 
of objects as concepts, and it is these concepts which are 


used to build classes. Concepts can have a name 
(representative symbol), an intension (definition), and an 
extension (the group of objects the concept applies to). Note 


that this way of viewing classes does not require that OOP 
objects parallel real-world objects so much as that they 
parallel human cognition of these objects. Moreover, this 
view also lends itself to defining ‘unreal’ or imaginary 
objects. 
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These auxiliary methods are a form of knowledge about class 
instances which users do not need to know. 

An interface to a class consists of those variables 
and methods which are visible to other objects and to 
subclasses (defined in Chapter II/Section 3)”. The interface 
available to other objects is called the "external view" and 
the interface available to subclasses is called the "internal 
view."® (Micallef, 1988, pg. 13) 

Not every OOPL offers a means for limiting the various 
interface visibilities. Those that do (C++, for example) 
provide mechanisms EOL eONEOLeING private. and public 
Sastinctions. Private variables and methods represent 
knowledge that is not known by other objects, and therefore 
are not part of the external or the internal interface. 
Public variables and methods are known and integrated into the 
external and internal interfaces. Generally, encapsulation is 
best enforced if variables are kept private, accessible only 
through public methods. An additional level of control can be 
applied to the internal interface: variables or methods can be 

"An interface can also be viewed as the set of behaviors 
an object makes available for use by other objects. 

"Note that a third interface to new objects is sometimes 
mentioned in the OO literature. (Micallef, 1988) This 
interface involves decisions about the external interface, 
initialization procedures, and class variables which will be 
made available to instantiations of a class. Also, the 
various views are called interfaces (for example, the external 


view is the same as the external interface). 
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declared protected which renders them visible to subclasses 
but not to other objects’. 

As previously noted, classes also constitute the key 
modules in most OO languages. Class modularity serves the 
objectives stated above and will be explored in the following 
subsections. The capability of classes to serve as a pattern 
for object declaration ensures consistent realization of these 
objectives in an OO program. 

2. Classes as Abstract Data Types 

Coad and Yourdon quote the Dictionary of Computing 
(Oxford University Press, 1986) in defining data abstraction 
as "...the principle of defining a data type in terms of the 
operations that apply to objects of the type, with the 


constraint that the values of such objects can be modified and 


observed only by the use of the operations." (Coad and 
YOuTdon elo), wea) Meyer notes that in describing data 
structures it is desirable to have complete, precise, 


unambiguous descriptions that are not based on the physical 


"In Ctt, there is an interesting split in control over 
the internal interface. (Atkinson and Atkinson, 1991) A 
superclass may declare class features to be private, 
protected, or public. However, it is the subclass which 
determines how public, private, and protected visibility 
declarations are inherited. The visibility of inherited 
features can be declared public, private, or protected. The 
declaration mechanism essentially allows a subclass to 
redeclare inherited public features as protected or private, 
and inherited protected features as private. Inherited private 
features remain private to the superclass - subclasses as well 
as users do not enjoy access privileges to these features. 
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representation of the underlying structure. (Meyer, 1988) An 
abstract data type (ADT) specifies a class of data structures 
fmeenot by implementation» but by the list of services 
available on the data structures, and the formal properties of 
these services." (Meyer, 1988, pp. 53-54) 

The data structure and associated services of an ADT 
conceptually form a unified whole. The separation of visible 
services from implementation details, central to the notion of 
an abstract data type, is accomplished by an interface which 
describes the services which the type performs. Consequently, 
a user of a data type understands the type as a closed 
description of behavior, the successful use of which requires 
only knowledge of the interface. 

In many OO languages, such as Eiffel (Meyer, 1988) and 
C++, classes are equivalent to ADTs. Hence, classes, the 
modular units of interaction, assume a specific purpose: the 
description of data types. The interactions between modules 
(classes) are managed through the type interfaces. 
Nevertheless, it is important to understand that the principle 
function of classes is to serve as templates for object 
instantiation and not as predicate descriptors. (Wegner, 1988) 
This critical difference assumes significance when considering 
inheritance (described in the next section) in which classes 
maintain set/subset relationships to facilitate code sharing. 
The mechanisms for inheritance do not always meet the strict 
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requirements for type/subtype behavioral compatibility which 
the class/type equivalence requires. 
3. Classes and Encapsulation 

Although classes specify the behavior of data types, 
aS modular software components they also embody the 
implementation details on structure and behavior. 
Modularization permits the design of interfaces which 
encapsulate these implementation details, thereby achieving 
the many benefits attributed to information hiding in Chapter 
I. The class interface need not include auxiliary methods, 
further increasing encapsulation. Hence, the class interface 
not only describes services available to users, but limits the 
ability of users to directly know, access, or modify the 
actual data structure of a class. 

Encapsulation represents a property, but not a 
responsibility of classes. Programmers must specifically 
design interfaces which segregate implementation from 
specification, and the OO philosophy of the language must 
support encapsulation by restricting access/manipulation of 
data structures to the designed interface. It is curious that 
not every OO language supporting classes enforces 
encapsulation as described. Instance variables in Simula, for 
example, are directly accessible. (Micallef, 1988) For 
reasons adduced in Chapter I, this undesirable condition 
increases the linkages among program modules, diluting the 
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reliability of code, and increasing the difficulties attendant 
to maintenance. 
4. Categories of Classes 
Within the context of software system design, classes 
serve varying purposes depending upon the requirements of the 
problem and the nature of the knowledge being modeled. These 
class roles generally reflect design decisions about how 
knowledge of data types should be distributed in the evolving 
erass Structure. 
a. Abstract Classes 
Abstract classes appear at the higher levels in 
inheritance hierarchies (discussed in the next section). 
Jumping ahead, an abstract class serves as a placeholder of 
methods and data common among the descendant classes in a 
hierarchy. (Wu, 1991) Hence, an abstract class serves as a 
repository of knowledge held in common by all of its 
descendent classes. As such, abstract classes are not 
intended to serve as templates for object instantiation. 
Rather, they eliminate the duplication of knowledge among 
related types, thereby reducing coding complexity and 
faemitating testing, debugging, and maintenance. 
Additionally, abstract classes also promote the design of a 
common protocol (interface) among the related types. This 


figures importantly in languages emphasizing polymorphism. 
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b. Concrete Classes 
Concrete classes are simply classes that are 
intended to serve as templates for object instantiation. Note 
that a concrete class may or may not be descended from an 
abstract class. However, it has been suggested that it is 
possible that abstract classes should not be descended from 
concrete classes. (de Paula and Nelson, 1991) 
c. Virtual Classes 
Virtual classes (C++ terminology) contain virtual 
methods. Virtual methods are those methods in a class whose 
implementations may be overridden (redefined) in descendent 
classes. This allows method names and sic .atures to be shared 
(see Section E on polymorphism). It should be noted, however, 
that many OO languages do not include this concept - any 
method of any class may be overridden in descendent classes. 
d. Pure Virtual/Deferred Classes 
Classes may exhibit behavioral commonalities that 
designers want to place into abstract classes without forcing 
a common implementation. Pure virtual classes (Gar 
terminology) allow for the specification of interfaces, part 
or all of whose methods are to be implemented in descendent 


classes®. 





"The concept of pure virtual functions should not be 
confused with the concept of subclass responsibility. Pure 
virtual functions are employed to ensure such methods form 
part of the interface of descendent classes. Subclass 
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Meyer refines the concept of pure virtual classes, 
arguing that such deferred classes (Eiffel terminology) 
Beereronally require the specification of logical pre/post 
conditions for deferred implementations. (Meyer, 1988) 
Paeeaough COLrrect in principle, it is difficult to discern how 
this complication assists design since a behavior is elevated 
to virtual status precisely because it is shared by 
descendants, and should therefore demonstrate the same 
semantic properties in descendent implementations. 

d. Parameterized Classes 

Parameterized classes are a form of generic 
eeructures. Such classes provide methods which operate on 
data structures whose types are not completely defined. An 
example would be a tree class for which the types of 
individual nodes are undefined. Another example would be an 
array class containing elements whose types are undefined. 
Current OO languages do not offer parameterized classes, 
although C++ designers are currently developing the technique 


for eventual introduction. (Budd, 1991) 


responsibility derives from the notion of $ functional 
decomposition (see Chapter IV). Specifically, subclass 
responsibility involves decisions about the distribution of 
methods among ancestor and descendent classes in cases where 
ancestor methods rely on the knowledge that descendants must 
implement certain methods. 
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e. Metaclasses 
Abstract, concrete, and virtual classes represent 
roles which classes can assume in the context of program 
design. In this capacity, classes continue to servew@as 
patterns for instantiation. Some OO languages (including 
Smalltalk, for example) carry through the object point-of-view 
to include all CSOonstruces in the language space. 
Consequently, classes must be treated as objects as well. 
This raises the requirement to create, initialize, and destroy 
classes. To accommodate these needs, such languages provide 
for metaclasses - classes from which class obyects are 
instantiated. "A class object is typically the only instance 
of a metaclass." (Budd, 19917 pq. > 
Metaclasses are a conceptual complexity which are, 
mildly expressed, difficult to understand. It is difficult 
to place an end to the recursion “ampliecit in detimeiing 
everything as an object. For example, consider this obscure 
passage from Budd describing metaclasses in Smalltalk: 
The class Class is a subclass of the class Object; and 
thus, the object Class points to the object Object as its 
superclass. On the other hand, the object Object is an 
instance of the class Class; and thus, Object points back to 
class. Class Class is itself a class, and thus an instance 
of itself. (Budd, 1991, pg. 265) 
Classes force instances to exhibit the same 


behavior; thus, metaclasses force classes to exhibit the same 


behavior. Metaclasses allow for class instances which 
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specialize the behavior of other classes. As an example, a 
class may need to override the constructor for an object 
defined by another class. The corresponding metaclass would 
allow for the overriding of the other class’ constructor. 

Carried to its logical extreme, the idea that all 
constructs in the programming environment are objects requires 
that "...the metaclass must be considered an object in its own 
right, and is therefore created by the metametaclass, which is 
in turn created by the metametametaclass, etc." (Nelson, 1990, 
mye 860 / ) Nelson points out that most OOPLS' supporting 
metaclasses ignore this problem, or simply declare metaclasses 
to be special objects provided by the system. (Nelson, 1990) 

Metaclasses clearly provide a higher level of 
abstraction; nevertheless, they also move away from the real- 
world parallelism that OO languages accentuate, forming a 
strange dual definition for classes, and are perhaps best 
relegated to theoretical discussions. 

5. Epistemological Issues 
a. Objects of Knowledge or Objects of Belief? 

An interesting side issue is the epistemological 
status of classes. Articles considering class design 
ordinarily contain a seemingly harmless footnote to the effect 
that design teams should possess at least one subject matter 
expert who presumably fully understands the problem domain 
from both a theoretical and experiential perspective which 
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supersedes the immediate application problem. At issue is 
whether the knowledge embodied by classes must be justified. 
As an example, an application modeling certain kinds of 
planetary phenomena may start from a Ptolomeic or a Copernican 
explanation of behavior and achieve reliable behavioral 
results. Yet, only the Copernican theory is justified as 
knowledge. If one objective of class design is to mimic the 
real-world, then designers should be required to justify to 
some degree the knowledge represented by classes. Too often 
in application design, belief is substituted for knowledge; 
much to the detriment of potential code reuse in new 
applications. 
e. INHERITANCE 
Inheritance uniquely distinguishes 00 languages from other 
programming languages. It has even been called the only 
unique contribution of OO languages. (Korson and McGregor, 
1990) Within the family of OO languages inheritance 
mechanisms vary widely. This section reviews the elasticity 
with which inheritance can be implemented, drawing out design 
implications for various inheritance strategies. 
1. Definition 

Inheritance enables the easy creation of objects that 

are almost like other objects with a few incremental 

Changes. Inheritance reduces the need to specify 

redundant information and simplifies updating and 


modification, since information can be entered and 
changed in one place. (Stefik and Bobrow, 1986, pg.41) 
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We adopt the view of Cook who defines inheritance as 
a composition mechanism that internalizes inherited 
attributes by late (execution time) binding of self- 
reference to the inheriting object. (Wegner and 
DOChriic tooo, DO. 97) 

Inheritance is here defined narrowly as a mechanism 


for resource sharing in hierarchies. (Wegner, 1987, 
PI Loo) 


A subclass inherits all of the variables and methods 
defined for its superclass - regardless of whether 
those variables and methods were defined locally in 
the superclass or inherited from some other class. 

(Nelsen, 1991, pq. Zz) 

Inheritance is a broad concept which serves multiple 
ends. Hence, inheritance must be approached from several 
perspectives to gain a fuller understanding of its conceptual 
diversity and utilitarian purposes. 

First, inheritance is primarily a resource sharing 
mechanism, greatly extending reusability. The idea that 
opportunities for economy of design exist can be drawn from 
the observation that classes of objects exhibit conceptual, 
behavioral, or structural commonalities. Spectiircally, 
inheritance is a mechanism which permits the definition of one 
class to include the specification or implementation of 
another class on the basis of these commonalities. 

Second, groups of classes can manifest collective 
commonalities which result in hierarchical relationships among 
the respective class definitions. Inheritance reifies these 
relationships into the actual implementation code. In the OO 


lexicon, an inheriting class is a subclass of the superclass 
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from which it directly shares implementation code, and it is 
a descendent of all classes to which a path (from the subclass 
to higher levels in the hierarchy) can be traced. Ali @ehe 
classes for which a given subclass is a descendent constitute 
the ancestors of that class. 

Third, inheritance is a pliant concept. Depending 
upon the nature of the commonalities instigating the decision 
to share code, restrictions can be levied which shape the 
kinds of code sharing that are permissible. These 
formulations of the inheritance mechanism are discussed in the 
following subsections. It should be noted, however, that 
conceptual and programmatic difficultie : often arise from 
language designs which emphasize but do not enforce particular 
inheritance restrictions. 

Fourth, some OO languages implement single inheritance 
in which a subclass is only allowed to inherit from a single 
superclass while other OO languages implement multiple 
inheritance (MI) in which a subclass inherits from one or more 
superclasses. MI is a technique which powerfully increases 
the opportunities for code reuse. However, MI also introduces 
several complications, solutions for which are not uniform. 
These problems are discussed in the MI subsection below, and 


further examined in Chapter V. 
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Finally, inheritance mechanisms can undermine other 
desirable OO language features. Chapter V considers potential 
conflicts engendered by inheritance. 

2. Inheritance Elasticity 

As previously stated, Classes provide instance 
variables, class variables, and methods, and they serve as 
templates for object instantiation. Inheritance entails 
decisions about the manner in which existing classes can be 
modified to form new templates. (Wegner and Zdonik, 1988) To 
facilitate discussion, inheritance can be described as a 
",...particular kind of incremental modification mechanism that 
transforms a parent entity P with a modifier M into a result 
entity R = P+M." (Wegner and Zdonik, 1988, pg. 55) P and M 
consist of sets of attributes (variables and methods) which 
may Or may not be disjoint. Disjoint attribute sets do not 
present any particular problem. Problems arise in determining 
the manner in which overlapping attributes will be treated. 

ite bears emphasizing that inheritance less a 
subclassing, not a subtyping’, mechanism. Inheritance 
realizes different kinds of templates depending on the 
constraints applied to the sharing of attributes. 

°"Subclassing is a set theoretical concept in which the 
members (variables and methods) of the subclass include all 
the members of the superclass. Subtyping is a behavioral 
concept in which any object of a subtype can be substituted 
for an object of the supertype and still respond to any 


service requests with the desired behavior. 
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a. Logical Possibilities 

Tt is useful to classify the various loegimeal 
possibilities for resource sharing under inheritance as either 
interface sharing or implementation sharing. An OO language 
may allow either or both of these forms of sharing, refining 
the individual categories through constraints. 

Interface sharing entails the reuse of a class’ 
interface, but not the actual implementation of the interface. 
Variable names and types are shared. Additionally, method 
names and parameters’® are shared. Interface sharing can 
assume the following forms’’: 

oVariable names and types are shared. 

°Method names and parameters are shared. 


oVariable and method names, types, and 
parameters are shared. 


Implementation sharing entails the sharing of 


method bodies. Such sharing offers the greatest opportunities 





Parameter sharing includes the names, number, and types 
of parameters as well as parameter qualifier distinctions (in 
versus out). 


“Note that signature sharing is purely a _ syntactic 
matter. (Wegner and Zdonik, 1988) Specification sharing 
provides for sharing descriptions of the effects of methods. 
(Krakowiak et al, 1990) Hence, specification sharing allows 
for semantic associations. "In the current state of the art, 
the specification is only a comment and is not subject to any 
formal processing. However, it is considered an integral part 
of the type definition.” {Krakowiak et al) 1990 ero 
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for code reuse. Implementation sharing can assume the 
following forms: 
oImplementation code is directly shared. 
oImplementation code is extended. 
coImplementation code is overridden. 


°Portions of implementation code are 
excluded. 


Logically separate from inheritance, but = an 
elemental consequence of the principles guiding the 
construction of class hierarchies, is the capacity to include 
new variables and methods in subclasses. Hence, inheritance 
takes shape aS a cross-product of the listed options and 
extendibility. In most OO languages, inheritance combines both 
interface and enone ton sharing. Virtual/deferred 
attributes allow for the inheritance of interfaces alone. 

The following subsections draw upon Wegner and 
Zdonik’s analysis of incremental modification in the context 
of inheritance. (Wegner and Zdonik, 1988) The authors assert 
that every class is a type describing a template. Their 
analysis is concerned with isolating the restrictions on 
inheritance (template modifications) that flow from different 
methods of specifying the behavior of types. The principle 
concern is that subtype behavior be compatible with supertype 
behavior. Different notions of compatibility emanate from the 


differing specification methods. There is a strong 
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predisposition that a class hierarchy should be structured to 
account for substitution possibilities (of subtypes for 
supertypes) . However, Wegner and Zdonik conclude that a 
strict interpretation of the subtype idea is overly narrow, 
intruding upon the flexibility which the subclassing mechanism 
permits. This leads inexorably to the conclusion that an OO 
language ought to provide weaker forms of typing/subtyping, 
thereby arming the programmer with the greatest leverage for 
designing class hierarchies. A supporting reason for such 
hierarchies is that objects in the real world do not often 
manifest relationships as conceived by strict subtyping, but 
exhibit a much richer set of Similarities that class 
hierarchies should emulate. 
a. Behavior Compatibility 

Behavioral compatibility "...may be specified by 
algebras with a signature and a semantics." (Wegner and 
Z0enwk, LISS pa. soe Hence, if classes are to be modeled 
such that the resulting class hierarchy doubles as a 
behaviorally compatible type hierarchy, then inheritance 
should be constrained to maintain a complete supertype/subtype 
relationship between superclass and subclass’**. This entails 
some notion about the requirements for complete behavioral 


compatibility in these relationships. Specifically, the 





“The critical notion is that the semantics of behavior 
must be compatible. 
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concept of substitutability must be defined for subtypes. 
Wegner and Zdonik define the principle of substitutability as 
follows: 
An instance of a subtype can always be used in any context 
in which an instance of a supertype was expected. (Wegner 
ema 4200niKk, L988, pg. 65) 
They then proceed to note that the only form of compatibility 
moeworeh this notion of substitutability is preserved is that 
kind of inheritance in which subclasses are restricted to 
adding new variables or methods??, and do not alter the 
Semantics (modify variable, argument, or result domains) of 
superclass features. (Wegner and Zdonik, 1988) The sort of 
compatibility envisioned is therefore both syntactic and 
semantic. It is doubtful that a practical compiler could be 
designed to determine complete behavioral compatibility, 
especially as such compatibility cannot be specified in 
current programming languages. 
Clearly, complete subtype compatibility is a 
highly restrictive notion and not enforced by current OO 
languages. In the analysis of class relationships, 
distinctions are often drawn between inheritance and type 
hierarchies. (Palsberg and Schwartzbach, 1990) Though many 
OOPLS identify subclassing with subtyping, it was previously 
noted that the two concepts are not the same. Consequently, 
“Wegner and Zdonik use the term "horizontal extension." 
(Wegner and Zdonik, 1988, pg. 64). 
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it is possible to design type hierarchies which do not 
parallel the class hierarchy. Based upon this distinction, it 
is of interest to note that so long as data structures are 
encapsulated, objects of a class (as a data type) whose 
interface syntactically parallels the interface of other 
classes should be substitutable for objects of these other 
classes independent of inheritance relationships. This notion 
of subtype compatibility appears feasible. However, languages 
such as Ct+ and Eiffel restrict subtyping to inheritance 
relationships to simplify the complexity of algorithms 
performing compile time type checking, therefore improving 
performance. 
b. Signature Compatibility 

Signature compatibility (syntactic compatibility 
as described above) drops the requirement for behavioral 
Compatibility In particular, the domains of inherited 
attributes may be modified. The term "vertical modification" 
describes such domain changes. (Wegner and Zdonik, 1988, pg. 
64) A signature compatible subtype (vertically modified) 
cannot be assigned to a_esupertype. A weaker form of 
substitutability is therefore offered in which an instance of 
a subtype can be used in read-only mode in any context a 
supertype is expected. (Wegner and Zdonik, 1988) The authors 
describe the relationships between entities in completely 
behavioral Conpatibi ie as consistent with VsSee 
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eemalchies.— However, as LaFonde and Pugh point out, ‘is a’ 
is not the same as subtype, but rather is a specialization 
relationship. (LaLonde and Pugh, 1991) Such relationships 
better coincide with Signature compatibility. 
c. Name Compatibility 

Name compatibility "...requires only the name and 
not the signature of the parent type to be preserved in the 
result." (Wegner and Zdonik, 1988, pg. 66) This is a simple 
and flexible form of incremental modification employed by many 
OO languages (such as Smalltalk). Name compatible 
modification entails searching the inheritance path (beginning 
With the result class) for the first occurrence of a name. 
Some OO languages modify the search algorithm by including 
Syntax which permits definitions to be directly selected from 
ancestor classes (such as double dot notation in Ct+t or 
‘super’ in Smalltalk). 

d. Selective Inheritance 

Selective inheritance** introduces the useful 
option of deleting inherited attributes. Selective 
inheritance, however, disrupts subtyping relationships should 
they exist. To facilitate reasoning about classes whose 
behavior is similar, but for which selective inheritance is 


employed, Wegner and Zdonik introduce the term "liketype." 


' 


“Wegner and Zdonik use the term "cancellation. ' 
fae 2aonik, 1988, pg. 67) 


(Wegner 
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(Wegner and Zdonik, 1988, pg. 73) Liketypes logically include 
the other incremental modification mechanisms. Consequently, 
the authors recommend using like relationships to structure 
inheritance hierarchies, applying constraints to the like 
relationship as needed to achieve desired compatibility 
relationships between superclasses and subclasses. 
Cancellation modification mechanisms alone provide 
for all the logical inheritance possibilities. Its 
interesting to observe that no OO languages that we know of 
implement cancellation mechanisms directly. The difficulties 
in managing intraclass linkages among attributes when 
cancellation is employed probably explains the absence of such 
cancellation mechanisms (as well as the adherence to some sort 
of strong typing philosophy). 
3. Specialization 

Several strategies can be employed to design class 
hierarchies. The possibilities include type, specialization, 
and like hierarchies. Additionally, classes may exhibit no 
abstract commonalties whatsoever other than code sharing or 
interface sharing. Inthe literature, however, specialization 
is typically described as the primary principle for hierarchy 
design. Yet, a precise formula for building such hierarchies 
has not found general acceptance. As the discussion in the 
previous subsection suggests, this probably reflects a desire 
on the part of designers to maintain maximum flexibility. 
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Specialization hierarchies are also called ‘is a’ 


meerarchies (e.g., an eagle ‘is a’ bird). Booch describes 
eas a’ hierarchies as consisting of "...superclasses 
representing generalized abstractions, and subclasses 


representing specializations in which fields and methods from 
the superclass are added, modified, or even hidden." (Booch, 
mol, pg. 56) 

What qualifies as specialized behavior? What 
correspondence should there be between the mechanisms which 
implement inheritance and the abstractions which relate 
classes in a specialization hierarchy? A return to 
epistemological issues is evident. It appears reasonable that 
a Standardized notion of specialization, based upon some sort 
of philosophical foundation, 1s required to introduce 
Sememmulty to hierarchy construction and to facilitate the 
construction of compatible hierarchies (which, afterall, form 
the OO libraries central to code reusability). 

Ultimately, the range of implementable hierarchies 
entails decisions about the distribution of responsibilities 
between programmers and language designers. Restrictive 
languages (basically strongly typed languages) ensure that 
programs are compiled in which undefined operations on objects 
are caught by the compiler. As flexibility increases, the 
programmer must ensure that undefined operations on objects do 
not happen (i.e., explicitly indicate to the system what class 
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relationships prevail so that the compiler or run[egn 
environment can enforce programmer intentions). 
4. Multiple Inheritance 

A subclass may inherit from several superclasses. 
Budd agrees that ‘is a’ relationships should” guidemeea— 
construction of MI hierarchies (directed acyclic lattices), 
noting, however, that the resulting subclass should be viewed 
as a specialized "...combination or collection of several 
different components." (Budd, 1990-3 2geeer 3) The idea of 
subclass as combination produces both the richness’ and 
difficulties that frame discussions about MI. In particular, 
what kinds of combinations should be permissible, and what 
status should be accorded subclass entities? Designers have 
not arrived at a consensus on these questions, which may 
explain why very few OO languages actually implement MI. 

MI also introduces new problems. Prominent problems 
include name conflicts and inheritance from a common ancestor. 
Name conflict resolution strategies must be developed. 
Knudsen provides a useful framework for analyzing such 
conflicts, distinguishing horizontal’? from vertical’® name 


Cou las t6m- (Knudsen, 1988) [uch Secon perce s can be 


Attributes with the same name are inherited from 
multiple superclasses. 


"Subclass possesses attributes with the same name as 
attributes in one or more superclasses. 
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characterized in three ways (Knudsen, 1988): (1) the same 
phenomena are defined; (2) casually related phenomena are 
Gefined; and, (3) unique phenomena are defined in which no 
collisions are permissible. The first method is handled by 
polymorphic techniques, the second by resolution operators”’ 
(such as double dot notation in C++), and the last will give 
rise to compile-time errors. 

Inheritance rom a common ancestor involves 
inheritance of attributes from superclasses whose inheritance 
paths converge at a common ancestor. At issue is the 
duplication of attributes. Should one or all attributes be 
inherited? If all are inherited, how are they to be 
distinguished? Solutions: to this problem are discussed in 
Chapter V. 

5. Delegation 

Some OO languages approach reusability from a 
different philosophic perspective. In lieu of classes and 
inheritance to facilitate sharing the implementation of 
template abstractions, these languages "...directly use 
objects as prototypes from which the default behavior for 
concepts can be reused." (Lieberman, 1986, pg. 214) An object 
can delegate its attributes to one or more prototypes. Hence, 
an object receiving a message may defer to another object to 

“Renaming or redefining subclass attributes is another 
Eemueron. (Budd, 1991, pg. 174) 


5,9 


formulate the response. Delegation is the mechanism for 
implementing this in these OO languages. (Lieberman, 1986) 
Proponents of delegation contend that it is more 
flexible and general than inheritance. Lieberman argues that 
inheritance fixes communication patterns between objects at 
instance creation time whereas delegation allows any object to 
serve as a prototype at any time. (Lieberman, 1986) However, 
delegation also carries the burden that objects are dependent 
on one another. Stein asserts that any changes to attributes, 
or their values, will affect both the object and the 
prototype. (Stein, 1987) More importantly, Stein presents a 
formal model which draws out the essent al implications of 
Classes qua templates: template instances are guaranteed to 
possess the same SEructumal properties, but value 
independence. (Stein, 29387) The very flexibility of 
delegation eliminates any sort of structural guarantees and 
value independence for objects in an object hierarchy. 
Delegation also raises epistemological questions. 
Given the run-time maneuverability of an object to delegate to 
other objects, it is perplexing as to what sort of knowledge 
is actually being modeled. Objects in a delegation hierarchy 
resemble amorphous entities amenable to the demands of the 
moment, but lacking assured structural or behavioral 


Cone auaay 
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Mime A COMpLomise Of Sorts to the inheritance 
versus delegation ‘controversy’ was decided by the Treaty of 
Orlando. (OOPLSA Addendum to the Proceedings, 1987) 
Provisions of the treaty accepted that the object sharing 
mechanism could occur along three independent dimensions: (1) 
Seaere Or dynamic’; (2) implicit or explicit’®; and, (3) per 
object or per group’®’. The position adopted in the treaty was 
",..that different programming situations call for different 
combinations of these features." (OOPLSA Addendum to the 
Proceedings, 1987, pg. 43) More than likely, the marketplace 
will be the final arbiter between the two approaches. 

D. COMPOSITION 
Another prominent relationship among real-world entities 
1s composition (also called aggregation); complex objects can 


be conceived as consisting (1i.e., being composed of) of 


pogmregates of other objects. Hence, an object is ‘part of’ 
another object (e.g., a wheel is ‘part of’ a car). Stefik and 
Bemrow consider a composite object to be "...a group of 


“The time that a system requires sharing patterns to be 
fixed (compile or runtime). (OOPSLA Addendum to- the 
Proceedings, 1988) 


“Sharing patterns can be declared by programmers 
(explicit) or automatically (implicit). (OOPSLA Addendum to 
the Proceedings, 1987) 


*°Sharing can be specified for an object at a time (per 
object) or for a group of objects at a time (per group). 
(OOPSLA Addendum to the Proceedings, 1987) 
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interconnected objects that are instantiated together, a 
recursive extension of the notion of objects (ster vaa 
Bobrow, L986, .pg-. >) Several ideas can be drawn from this 
conception of composite objects. 

First, composition is another mechanism for reusability. 
The class template for a group of objects may include the 
previously defined templates for other classes of objects - 
redefinition is not necessary. Booch notes that such 
composition relationships can be implemented through two 
mechanisms (Booch, 1991): (1) declaration of class instance 
variables as user defined types; and, (2) declaration of 
formal parameters for class methods as user defined types (as 
a parameter to the class interface). 

Second, the interconnectedness of objects in composition 
relationships occurs through the respective object interfaces. 
This serves to preserve encapsulation. Nevertheless, the 
interconnectedness also establishes a coupling between 
respective classes. The implications of this coupling will be 
examined in Chapter V. 

Third, composition should not be confused with inheritance 
(either single or multiple). In particular, Halbert and 
O’Brien point out that a "...subclass inherits from a 
superclass only once while aggregation allows more than one 
instance of a particular object type." (Halbert and O’Brien, 
Losi); pa. 76) 
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Fourth, the notion of composition aS a recursive 
definition highlights the fact that members of a composite 
object may themselves also be composite SpVyecrs. 
Consequently, any level of nested complexity is possible. 

Finally, it is interesting to ask how composite objects 
@eetrer from collections of objects cooperating collectively to 
achieve a systematic pattern of behavior. The answer is that 
the differences are mostly in the respective degrees of 
abstraction and complexity. Composite objects can themselves 
be viewed as systems (e.g., a car). However, the level of 
complexity and abstractness for systems such as a factory is 
elevated enough that it should not be localized into a single 
object. These application specific decisions reflect design 
considerations about the distribution of knowledge, and 
fest bility of objects. 

E. POLYMORPHISM 

Polymorphism is one of the more abstruse concepts in the 
OO literature. Consequently, a variety of approaches are 
taken toward delimiting its meaning. That inheritance, 
specialization, message passing, and polymorphism all interact 
to achieve reusability and extendibility further complicates 
isolating the content and effects of polymorphism. 

Budd observes that definitions of polymorphism often 
overlap other concepts such as overloading. (Budd,1991) This 
section reviews several polymorphic mechanisms without regard 
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to delineating the boundaries with overlapping concepts. The 
intent is to establish the manner in which OO languages 
implement polymorphism. 
1. Abstract Qualities 

In programming languages, "a polymorphic object is an 
entity, such as a variable or function argument; Chae. 
permitted to hold values of differing types during the course 
of execution." (Budd, 1991, pg. 185) Most OOPLS provide an 
efficient message passing construct that enables receivers of 
messages to change. (Ingalls, 1986) Finally, Meyer states 
that in strongly typed environments (such as Ctt, Eiffel, 
etc.), the changing among typeS or message receivers is 
constrained by inheritance. (Meyer, 1988) 

What emerges is the notion that polymorphism describes 
a group of mechanisms that permit programming constructs 
(i1.e., method names, method arguments, and objects) to shift 
definitions in the course of program execution. Individual 
languages must be studied to understand how the shifting is 
accomplished. For example, some languages distinguish the 
static, declared class of an object from the dynamic class of 
its value. (Meyer, 1988) Polymorphism is managed in these 
languages through manipulations of references and pointers. 
Other languages manage polymorphism by binding values to 


objects at run-time only. 
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2. Polymorphic Names 
This form of polymorphism occurs when the same message 
can be sent to different objects. It is commonly associated 
with the overloading of function names. Hence, several 
(possibly unrelated) classes may have a method with the same 
name. A standard example is the method print?’’. 
3. Polymorphic Names and Arguments 
Another variant of overloading occurs when methods 
with the same name have different argument cardinality or 
different argument types**. The methods are all grouped within 
a single class. A standard example is the constructor 


function in C++ classes. 


“For example, several classes may have a method named 
print which has no arguments. Individual objects from the 
different classes, when receiving the print’ request, 
understand that the local implementation of the print method 
is to be used. Polymorphism, used in this manner, avoids the 
undesirable construction of large case statements which match 
methods to objects. Such large case statements also assume too 
much knowledge on the part of one object about other objects. 


“Micallef describes this as "multiple polymorphism." 
(Micallef, 1988, pg. 32) in which there is more than one 
polymorphic variable. She distinguishes this from simple 
polymorphism in which the "operation invoked is dependent on 
the type of only one argument, the receiver of the object." 
(izeallef, 1988, pg. 32) The idea is that the same method 
name may be employed by different classes (simple 
polymorphism), or by more than one method within a single 
class (multiple polymorphism). 
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4. Varia 
The forms of polymorphism listed above represent the 

basic cases found in most OO languages. Budd additionally 
includes #everridang, a) 7a, deferred, and parametric 
techniques’*? among his list of polymorphic mechanisms. (Budd, 
oS) 
F. CONCLUSIONS 

The OO paradigm has evolved since the introduction of the 
first OO language, CEMBALO (Meyer, 1988), in 1968 to encompass 
objects, classes, and inheritance. It is inheritance (or 
delegation) which uniquely distinguishes OO languages from 
other programming languages. Languages w! ich include objects 
and classes, but not inheritance/delegation are called object- 
based languages (for example, Ada). Currently, the greatest 
impediment to the commercial ascendancy of the OO paradigm as 
the methodology of choice for language design is the lack of 


conceptual standardization. 


*°Overriding occurs when a subclass redefines the body of 
an ancestor method. The other techniques are discussed in the 
section describing classes. 
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III. OO DEVELOPMENT 


A. SOFTWARE ENGINEERING METHODOLOGIES 
Software engineering is the application of science and 
mathematics to the problem of making computers useful to 
people via software. (Berzins and Luqi, 1991, pg. 1) 
Software engineering finds its genesis in the perception 
during the 1960’s that software production was a disorganized 
process, the vagaries of which often resulted in avoidable 
increases in the total cost of software over the lifetime of 
e@eeproduct’. (Schach, 1990) Computer scientists set about on 
a scientific search for principles which would objectify the 
process of software development. As the discipline evolved, 
many of the software properties discussed in Chapter I were 
established. The search for development methods which 
accentuated these properties has naturally been influenced by 
the underlying philosophy (or paradigm) adopted for 
understanding application domains. 


Currently, many computer scientists are investigating 


strategies for managing a transition from non-OO based 


*The manifold problems which produced huge increases in 
the total cost of software during the 1960’s have collectively 
been termed the "software crisis." (Schach, 1990, pg. 5) 
Particular emphasis has been directed toward the excessive 
costs associated with software maintenance. (Booch, 1987) 
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development methodologies to 00 based methodologies’. A wide 
variety of opinion exists as to the preferred Coursesee. 
follow. This chapter reviews software development aspects 
programmers should consider in assessing the relative merits 
of various strategies, considers several approaches to 00 
development, and advances development recommendations. 

1. Lifecycle Organization 

In object-oriented analysis, we seek to model the 

world by identifying the classes and objects that form 

the vocabulary of the problem domain, and in object- 
oriented design, we invent the abstractions and 
mechanisms that provide the behavior that this 

model requires. (Booch, 1991, pg. 141) 

The advent of software engineerin produced a mindset 
which focused on decomposing complex ideas and processes into 
simpler ones. Decomposition of the development process itself 
produced models of varying constitution, but models usually 
included the following stages*: requirements analysis, 


specification, design, implementation, maintenance, and 


retirement. (Schach, 1990) Structured techniques based upon 


"For example, Booch 1991, Coad 1991, Li 1991, Pun 1991, 
Odell 1991, and Arnold 1991 all discuss new approaches to 
software development based upon the OO paradigm. Debate 
focuses on the most efficient manner in which to shift from 
current methodologies based upon structured techniques 
(analysis, design, and implementation guided by functional 
decomposition of the application domain) to OO techniques. 
Advocacy ranges from evolutionary to revolutionary strategies. 
(ie oo) 


"These stages are collectively referred to as the 
"software lifecycle." (Schach, 1990, pg. 43) 
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functional decomposition were used to further simplify each 
stage in the software lifecycle. 

The OO development process is generally structured in 
terms of OOA, OOD, and OOP. OOA is concerned with defining 
concepts in the problem domain. It is through OOA that 
knowledge about the real-world is captured‘. OOD extends the 
results of OOA, uncovering entities missed by OOA, others that 
meet user requirements, and still other entities that are 
needed to consolidate an application into a serviceable tool 
(for example, user interfaces and task managers). OOP 
involves the actual implementation of the results of OOD. 
There is no rigid formula for conducting these stages; various 
temporal schemes can be utilized, the net results of which are 
iterative development processes best described as "...round- 
mam gestalt." (Booch, 1991, pg. 188) 

Debate exists over "...whether to replace structured 
techniques and functional decomposition by object-oriented 
techniques, or whether to look for a pragmatic solution in 
which existing investments are retained to a significant 
degree and tools and methods modified to encompass the object- 
oriented paradigm’." (Henderson-Sellers and Constantine, 1991, 

*Hence, as suggested in Chapter II, OOA requires subject 
matter expertise. 

"Henderson-Sellers and Constantine note that the 
OOA/OOD/OOP breakdown can be handled in any of several ways. 
That is, though the objective of each stage is to produce OO 
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pg. 18) Consequently, strategies for OO development entail 
decisions about which techniques to apply during each 
lifecycle stage. Ultimately, where an analyst falls on this 
issue largely depends upon his philosophical predisposition to 
adhere to purely OO concepts and techniques, and upon the 
availability of OO development environments®. Currently, the 
preponderance of development strategies employ modified 
structured techniques’. 

It should be pointed out that OOA/OOD concepts and 
techniques are serviceable tools for development leading to 
implementation in non-OOPLs. The OO approach to knowledge 
representation (objects and their relationships) facilitates 


problem understanding in a-manner that is transferable to non- 


results, the techniques adopted at a given stage may be purely 
OO, or they may be structured techniques modified to produce 
OO usable results. (Henderson-Sellers, 1991) The critical 
question is whether structured techniques can in fact be 
facilely modified to accommodate OO thinking. The answer to 
this question entails both conceptual and economic 


considerations: (1) can techniques based upon functional 
decomposition be used to uncover fundamentally different 
entities and relationships (i.e., objects, classes, and 
inheritance); and, (2) can structured techniques, if used, be 


employed efficiently with a minimum of modification. 


°It is one thing to argue for purely 00 techniques, quite 
another to actually provide such methods and tools. 


"Data flow diagrams (DFD), entity relationship diagrams 
(ER), state transition diagrams, or event-response diagrams 
are incorporated into many OO development approaches. For 
example, Booch 1991, Rumbaugh 1991, and Li 1991 all include 
some of these techniques as part of their development 
methodology. 
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OO programming. Specifically, OOA/OOD can serve to structure 
high-level abstractions which can then be tailored to suit the 
requirements of individual programming languages. 
2. Conceptual Organization 
When investigating proposed approaches, Lee Ss 
important to consider the primary conceptual blocks (or 


models) used to abstract a problem: does an approach directly 


compose analysis in terms of objects, classes, and 
hierarchies? Many structured techniques do not abstract 
problem entities in this manner. In particular, structured 


techniques map real-world entities to functions and data. (de 
Champeaux et al, 1990, pg. 135 - 139) Heuristics must then be 
aepbred to transition to an OO conceptualization. 

Two other difficult development problems must also be 
investigated. First, OO development requires methods for 
recognizing and structuring systems. For present purposes, 
systems analysis in the OO framework is narrowly conceived of 
as a process which determines groupings of objects that 
accomplish some pattern (or subpattern) of collective 
behavior. At issue is how analysts go about identifying and 
relating these abstractions. The problem is a subtle one 
Since the system behavior, exercised as collections of 
cooperating objects, is diffused throughout the class 
hierarchies. Analysts are therefore confronted with a twofold 
problem: (1) determine the functional responsibilities of a 
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system and its constituent subsystems; and, (2) determine the 
best manner for distributing these behaviors among the 
classes. Few proposed OO development approaches adequately 
handle this analytical problem; a problem, it should be noted, 
that structured techniques manage quite well. 

Second, reusability inevitably covers the entire 
development spectrum. Viewed from this perspective, it is 
appropriate to question how development should be conducted 
given that analyses, designs, and programs can be reused as 
elements in future development efforts. Specifically, OOA, 
OOD, and OOP no longer focus solely on the present project, 
but potentially supply source material for future projects. 
What concepts should guide development under these 
circumstances? Are some designs more reusable than others? 
Can potential reusability be measured? Clearly, reusability 
requires further research. 

3. Notational Organization 

Closely allied to conceptual organization is the 
notational scheme adopted. Are the transitions between 
development phases enhanced or impeded by notational tools? 
Does the notation employed completely and consistently 
describe the models being used for understanding a problem 
(Arnold et al, 1991)? In particular, is a consistent 
representation utilized? It has been argued = that 
representational shifts have stymied developers as they move 
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from analysis to design. (Coad and Yourdon, 1991) A solution 
is arrived at IY applying a uniform underlying 
representation for organizing data and its exclusive 
processing - that of Classes and Objects within those 
easses...." (Coad and Yourdon, 1991, pg. 21) Again, 
approaches vary according to the philosophic adherence to pure 
OO concepts and techniques. 
B. OO DEVELOPMENT APPROACHES 

OO practitioners are in search of methods whose logic is 
infused from the start by 00 constructs and objectives. Given 
the lack of standardization in the field, it is not surprising 
that there exist wide differences in OO development 
approaches. The positions advanced by some of the better- 
known OO advocates will now be reviewed. 

1. Coad/Yourdon 

In apprehending the real world, men _ [people] 


constantly employ three methods of organization, which 
pervades all their thinking. (Coad and Yourdon, 1991, 


oe) 

Coad and Yourdon proceed on the assumption that 
analysis/design thinking should parallel the patterns by which 
people ordinarily organize knowledge. The three methods of 
organizing knowledge are (Coad and Yourdon, 1991): (1) objects 
and their attributes; (2) distinctions between objects and 
component parts; and, (3) distinctions between classes of 


objects. This knowledge is garnered in OOA through five 
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activities (Coad and Yourdon, 1991): (1) finding eel. 
objects; (2) identifying structures; (3) identifying subje@es, 
(4) defining attributes; and (5) defining services’®. The 
activities can be pursued in any order, and generally move 
from higher to lower levels of abstraction. 

OOD, in the Coad/Yourdon approach, takes the results 
of OOA and further refines the organization of knowledge. 
Additionally, specific requirements of the application are 
introduced by organizing design into four components (Coad and 
Yourdon, 1991): (1) the problem component, which models the 
real-world problem space; (2) the human interaction component, 
which models how a human will command system and how a 
system will present information; (3) the task management 
component, which addresses concurrency control; and, (4) the 
data management component, which provides the infrastructure 
for the storage and retrieval of objects from a data 
management system. OOA results form the bulk of the problem 
domain component. 

As analysis and design is refined, particular emphasis 


should be applied to reducing connections between objects and 


°Class-&-objects assume their usual meaning, structures 
include generalization-specialization and whole-part 
structures, subjects are mechanisms INORG guiding 
analysts/experts through complex models, attributes are data 
maintained about the state of an object, and services are 
behaviors objects are responsible for. (Coad and Yourdon, 
1991) 
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between classes. (Coad and Yourdon, 1991) Specifically, they 
recommend controlling the following forms of coupling (Coad 
and Yourdon, 19 Od (1) interaction coupling (limiting 
parameters in messages to three or fewer, and simplifying the 
number of messages sent and received by individual objects) ; 
and, (2) inheritance coupling (maximizing superclass/subclass 
connections along generalization-specialization lines). The 
authors also recommend that cohesion be maximized as follows: 


(1) services should carry out one function; (2) classes should 


contain no extra attributes or services; and, (3) inheritance 
should portray specialization cohesion, not sacbitrary 
relationships. 


Though great emphasis is placed upon the use of a 
unifying OO notation, comparatively little advice is directed 
toward actual development tools. The authors do advocate 
utilizing a CASE tool for OOA, and also recommend using 
summary cards for manually conducting analysis and design. 
(Coad and Yourdon, 1991) 

2. Booch 

Object-oriented design is not a process that starts 

with a requirements specification, ends with a 

blueprint for implementation, and requires a miracle 

somewhere in between. We suggest that it allow an 
evolutionary development, a view consistent with 

Boehm’s spiral model of software development. (Booch, 

SON a pg. 190) 

We believe that Booch’s discussion on OOA and OOD 


(Booch, 1991) is as much a diatribe on OO philosophy as it is 
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on OO techniques. Particular care is taken to emphasize that 
the OO approach to software development is a voyage of 
discovery and invention for which there are no hard and fast 
rules. Consequently, considerable effort is spent explaining 
the limited applicability of structured techniques and 
waterfall lifecycle development. Structured techniques tend 
to reflect a bias toward algorithmic decomposition 
inappropriate to real-world modeling of interacting objects, 
and the waterfall lifecycle is a "...fundamentally poor 
process, and generally violates many of the principles of 
sound engineering practice. " “Booch, ss 77l, pawl) 

The foundation of the Booch approach is the isolation 
and iterative refinement of problem abstractions. He directly 
confesses that OO development is a fuzzy process in which 
domain expertise, experience, and intuition all play a role in 
uncovering relevant abstractions at appropriate levels of 
detail. In describing this evolutionary process, he 
highlights four prominent activities and illustrates several 
techniques, as described in the following subsections. 

Development, for Booch, focuses on defining three 
principal constructs: objects, classes, and mechanisms. The 
following subsections review Booch’s suggested techniques and 
organizing activities. 


a. Techniques/Notation 
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Booch underlines the need for taking multiple 
views on complex systems. (Booch, 1991) Hence, he advocates 
the use of the following diagrams: class, object, module, and 
process. The first two diagrams describe the logical view of 
a system while the last two describe the physical structure of 
a system. These diagrams capture static semantics. Dynamic 
system properties are captured in state transition diagrams 
and timing diagrams. Collectively, these techniques preserve 
the knowledge garnered during the four organizing activities. 

Class diagrams indicate class relationships’, 


class utilities’®, class categories", superclasses, fields, 


and operations. State transition diagrams show the state 
space of a class - events causing state transitions. Object 
diagrams "...show the existence of objects and their 
relationships in the logical design of ae_esystem, and 


illustrate the semantics of key mechanisms in the logical 


design." (Booch, 1991, pg. 169) Hence, object diagrams are 


*Class relationships include inheritance, instantiation, 
using, and metaclass relationships. (Booch, 1991) 


Class utilities are free subprograms. (Booch, 1991) 
That is, they are operations which are not meaningfully 
encapsulated by any particular object. Instead, these 
operations are grouped into utility classes from which they 
are accessible, but cannot be redefined. (Booch, 1991) 


“Class categories are logical collections of classes. 
Bach class within a category has an associated visibility: 
private to the category, externally visible, or imported from 
another category. (Booch, 1991) 
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used to depict object properties, relationships, visibility, 
and message synchronization. Timing diagrams indicate the 
flow of control among collaborating objects. Module diagrams 
show the allocation of classes and objects to modules, and 
module visibility. Booch uses subsystems to group logically 
related modules. Finally, process diagrams describe processor 
allocation for applications with concurrent tasks. 
b. Activities 

Booch maintains that four activities typify OO 
development (Booch, 1991): (1) identify classes and objects at 
a given level of abstraction; (2) identify the semantics of 
classes and objects; (3) identify relationships among classes 
and objects; and, (4) implement classes and objects. The 
first activity involves "...the discovery of key abstractions 
in the problem space and the invention of important mechanisms 
that provide the behavior required of objects that work 
together.”  (Boceh,- 19915) (paws. ol) The second activity 
",..establishes the meanings of classes and objects, viewing 
each class from the perspective of its interface." (Booch, 
1991, pg. 192) The third activity establishes "...how things 
interact within the system." (Booch, 1991, pg. 193) Finally, 
the fourth activity involves "...design decisions concerning 
the representation of the classes and objects we have 
invented, and allocating classes and objects to modules, and 
programs to processors.” (Booen, 99 poe ls] 
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3. Wirfs-Brock 

Model your design as clients and servers who 

collaborate in ways specified by contracts. 

(Wirfs-Brock, Wilkerson, and Wiener, 1990, pg. 32) 

The Wirfs-Brock approach to design squarely focuses on 
maximizing and preserving encapsulation. (Wirfs-Brock and 
Wilkerson, 1989) The client-server concept moves analysis 
toward a responsibility-driven, contract perspective on entity 
interactions which forces analysis and design away from 
implementation/structural details and closer to behavioral 
abstraction. (Wirfs-Brock and Wilkerson, 1989) 

Analysis in the exploratory phase of system design 
moves in the following directions (Wirfs-Brock, Wilkerson, and 
Wiener, 1990): (1) Findoo ject S ; (2) determine object 
responsibilities; and, (3) determine object collaborations’. 
Heuristics and guidelines are offered to conduct the process. 
It is recommended that class cards be maintained to record 
information about classes, class responsibilities, and 
collaborations. 

Wirfs-Brock proposes that the next phase of design 
focus on structuring inheritance hierarchies using hierarchy 


Graphs, Venn diagrams, and contract analysis. (Wirfs-Brock, 


*Collaborations entail class interactions. Such 
interactions are uncovered by analyzing class communication 
paths, particularly WS pag Of , has knowledge of, and 
depends upon communication. (Wirfs-Brock, Wilkerson, and 
Wiener, 1990) 
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Wilkerson, and Wiener, 1990) During this phase many 
distinctions are drawn out (Wirfs-Brock, 1990): (1) abstract 
and concrete classes are determined; (2) ‘kind of’ 
hierarchies are built in which common responsibilities are 
moved up the hierarchy, abstract classes are added, and 
unnecessary’? classes are eliminated; (3) contract analysis 


directs the reassignment of responsibilities, and the 


uncovering of new responsibilities; (4) class cohesiveness is 
maximized; and, (5) the number of class contracts is 
minimized. The overriding objective is that "...each class 


have a single, overarching purpose; each class should serve 
one main function in the system of wh: sh it is a part." 
(Wirfs-Brock, Wilkerson, and Wiener, 1990, pg. 121) 

Finally, and most interestingly, collaboration graphs 
and subsystem cards are employed to streamline collaborations 
among classes**. (Wirfs-Brock, Wilkerson, and Wiener, 1990) 
Again, heuristics and guidelines (emphasizing collaboration 
analysis) are offered to assist in identifying subsystems. 
Proposals include the following (Wirfs-Brock, Wilkerson, and 


Wiener, TSENG oe (1) drawing collaboration graphs; (2) 





“Unnecessary classes are those which do not’ add 
functionality. (Wirfs-Brock, Wilkerson, and Wiener, 1990) 


“Collaboration graphs describes communication paths among 
classes, and subsystem cards describe a subsystem’s 
responsibilities (contracts) and the class to which the 
contract is delegated. (Wirfs-Brock, Wilkerson, and Wiener, 
1990) 
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determining strongly coupled classes (including transitively 
coupled classes); (3) simplifying and minimizing interactions; 
(4) minimizing subsystem responsibilities delegated to a 
class; and, (5) minimizing contracts supported by a subsystem. 
The general idea is to efficiently distribute responsibilities 
throughout the hierarchies on the basis of contract 
considerations stimulated by subsystem analysis. 
C. RECOMMENDED OO ANALYSIS AND DESIGN METHODS 

The OO methodology for representing knowledge about real- 
world objects is comparatively straightforward. However, 
determining the relevant objects and their systematic 
ieeracionships is difficult. A particular sticking point is 
the lack of strategic thinking on systematic organization. 
This is, perhaps, unavoidable for a methodology that selects 
objects and not processes as the analytic ambit. 

There are no rigid formulas for conducting OOA and OOD. 
As demonstrated by the various approaches discussed in the 
previous section, these steps iteratively inform and improve 
one another. However, certain themes can be culled which can 
be applied as a ‘backbone’ upon which tailored modifications 
can be extended. These themes can be thought of as 
recommendations for organizing OOA and OOD: 

°oIn a concession to structured design, functionally 
decompose a system into its major constituent 


subsystems. This decomposition should serve as a 
checklist against which the actual evolving design 
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can be assessed to ensure that principle subsystem 
responsibilities are accounted for. 


oComplement system analysis with a parallel analysis 
of supporting application requirements - concurrency 


COniPLol, interface, and database management. 
Maximize reuse of previously designed application 
code. When possible, allow application support 


objects to perform subsystem responsibilities’. 
oAnalyze principle subsystem responsibilities. 


oIdentify problem domain objects/classes. Subject 
experts, and prior designs should be exploited to 
the maximum extent possible. 


°Analyze principle object responsibilities. Note 
collaborations among objects’®. 


eAnalyze object variables. Decide state information 

that each object needs to preserve to fulfill 
responsibilities. Account for variables shared by 
objects, variables that can be calculated, and 
variables that can be decomposed’’. (dePaula and 
Nelson, 1991). 


°Group objects into subsystems. Note that an object 
may participate in more than one subsystem. 


oCheck to ensure that cooperating objects account for 
behavior expected from respective subsystems. Adjust 
object collaborations Ee achieve efficient 
distribution of system responsibilities: promote 
tight object/class cohesion, minimize ob ject/class 


“Integrating problem domain responsibilities into 
application object responsibilities is one of the more subtle 
and difficult tasks faced by the analyst/designer. 


**Analysis should allow for decisions already embedded in 
available libraries. 


“Variable decomposition takes account of composition 
relationships. (dePaula and Nelson, 1991) 
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linkages within a subsystem, and reduce the number 
of message parameters where possible’®. 


°Group Classes into specialization hierarchies’’. 

This presupposes a decision about the semantics 
which will control the formulation of specialization 
relationships. 


oStreamline class hierarchies. This includes 

segregating abstract from concrete classes’, 
factoring common methods as high as possible, and 
eliminating unnecessary classes. (dePaula and 
Nelson, 1991) Note that common protocol design will 
include decisions about virtual and pure virtual 
features. 


Tools for assisting analysis/design can be located in the 
various approaches previously listed. CASE tools created 
specifically for OO purposes should be used when available. 
However, when considering CASE tools, many of the issues 
discussed in Section A need to be carefully assessed. 

These recommendations constitute a starting point. An 
analyst must first ensure that a strong foundation in OO 
techniques and philosophy has been acquired - knowledge which 
extends beyond mere facility with a particular pure or hybrid 

Man object overburdened with subsystem responsibilities 
suggests that the object/class should be decomposed into 
smaller, more specialized objects/classes. This will assist in 
promoting object/class cohesion. 

*~Note that hierarchy construction requires prior 
consideration of OOL selection - single or multiple 
inheritance strategies must be decided. Also, multiple 
inheritance strategies must account for resolutions to 
conflicts discussed in Chapter II. 

*°Abstract classes should formulate a common protocol. 
Additionally, abstract classes should not inherit from 


concrete classes. (dePaula and Nelson, 1991) 
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OOPL. This foundation will be needed to resolve many of the 


OO mechanism conflicts which are addressed in Chapter V. 
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IV. FUNCTIONAL DECOMPOSITION AND 
SUBCLASS RESPONSIBILITY 
A. FUNCTIONAL DECOMPOSITION 
Chapter III considered the applicability of structured 
design techniques to OO problems. Although the emphasis of 
structured design falls squarely upon procedures and not 
objects, many of the concerns which prompted structured design 
in the first place (modularity, flexibility, reliability, 
cohesion, coupling) receive corresponding importance in OOP. 
Hence, it is not unreasonable to expect that some of the 
arguments, if not techniques, of structured design applies to 
OOP. This section addresses one area which merits attention: 
functional decomposition. 
1. Functional Decomposition and Subclass Responsibility 
It has been noted that the pure OO methodological 
framework "...does not totally neglect structured tools and 
experience; rather, it defers it to a more detailed design 
level." (Henderson-Sellers and Constantine, 1991, pg. 14) 
Specifically, design of methods is "...essentially identical 
to structured, functional decomposition as developed over the 
last twenty years or so." (Henderson-Sellers and Constantine, 
moot, pg. 14) Observe that "this does not contradict the 


object-oriented paradigm since at this level the 
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implementation of the features is hidden and changes in the 
implementation therefore have, at least in principle, no 
repercussions on the rest of the software system." (Henderson- 
Sellers and Constantine, 1991, pg. 14) 

Several software qualities and heuristics have been 
identified as conducive to better structured designs. (Yourdon 
and Constantine, 1978) In the context of structured design, 
a module is identified with a single functional purpose. The 


unifying purpose varies according to the organizing strategy 


adopted (for example, transaction analysis or transform 
analysis). Modules are decomposed (procram structures are 
organized) by assessing, among other -hings, factoring’, 


cohesion’, and coupling’. Given the identification of modules 
with functional purpose, this resolves into a process of 
functional decomposition. 

Cohesion, coupling, and factoring are also relevant to 


the design of methods. Subclass responsibility was previously 


‘Factoring is a term which describes the degree to which 
control and coordination functions are performed by higher- 


level modules in a hierarchy (produced by modular 
decomposition), and processing is delegated to subordinant 
modules. (Yourdon and Constantine, 1978). 


“Cohesion reflects a semantic or procedural unity 
exhibited by statements which suggests bundling into a single 
module is appropriate. 


Coupling is a measure of the degree to which separate 
program elements are independent of one another. (Yourdon and 
Constantine, 1978) 


66 


defined (Chapter II) as a Situation in which ancestor class 
methods rely on the knowledge that descendants must implement 
certain methods. As such, a design providing for subclass 
responsibility can be viewed as a subset of functional 
decomposition. 

Figure 1 can be used to illustrate subclass 
responsibility. Superclass A contains methods 1 and 2 while 
subclasses B, C, and D contain methods 3 and 4, 5 and 6, and 
3 and 7 respectively. Method 1 invokes method 3, but Class A 
does not implement it. This situation therefore requires that 
Class A be implemented as an abstract class, or that an 
instance of Class A cannot call method 1. The invocation of 
method 3 takes the form self->3. Observe that subclasses B 
and D implement method 3, but that subclass C does not. Thus, 
Class C, like Class A, must either be an abstract class or 
instances of Class C cannot call method 1. Finally, methods 


mo, and 7 simply indicate that other methods may be 


Class A 


method 1 
method 2 : 
| 
i 
Class B Class C Class D 
method 3 method 5 method 3 | 
method 4 method 6 method 7 | 


Figure 1: Subclass Responsibility 
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implemented by subclasses. In this example, these other 
methods do not interact with method 3 or method l. The 
following subsections review problems associated with subclass 
responsibility and use of cohesion, coupling, and factoring to 
reduce these problems. 
a. Subclass Responsibility 

Subclass responsibility does not fit easily into 
the design recommendations listed in Chapter III. First, as 
illustrated in Figure l, it is questionable whether subclasses 
Should be allowed to exclude methods assumed to be 
implemented. This may be possible for liketype systems as 
described in Chapter II, but should not be attempted in 
dynamically typed languages. A class may legally inherit, 
but not implement a pure virtual method. In a strongly typed 
language such as Ct+, such classes are automatically 
recognized as abstract classes. Hence, run-time errors will 
not occur since objects from these classes cannot be 
instantiated’. No such protective mechanisms are available in 
dynamically typed languages like Smalltalk. Consequently, the 
onus is shifted to the designer to ensure that all possible 
avenues for arriving at such an invocation are precluded. 

Second, subclass responsibility clearly 
establishes an undesirable coupling between ancestor and 

“It is assumed the design recommendation that abstract 

Classes not inherit from concrete classes is also observed. 
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descendent classes. It requires a cooperative design effort 
between respective class designers. Notice that it also 
requires that descendent classes have some awareness of 
ancestor class implementations (i.e., method 3 occurs in the 
specific context of method 1). 

Third, in languages such as C++, method 3 must be 
declared (although not defined) in Class A. Why not supply 
default behavior, perhaps an error message, to protect 
designers of descendent classes? In other words, employ 
virtual functions which can be overridden by descendent 
classes. 

Boise i, it was asserted in Chapter III that 
abstract classes should provide a common protocol and define 
common behavior for descendent classes. Again, if subclass 
responsible behaviors (for example, method 3) are not 
applicable to all concrete descendants (for example, Class C), 
they should not, under this formulation, be designed into the 
concerned abstract class. 

Finally, designers must carefully consider the 
visibility of subclass responsible behaviors. Given the 
linkages (discussed below) established by subclass responsible 
design, it is questionable whether such behaviors should form 
part of the external interface. 

The preceding discussion leads to the following 
recommendations when employing subclass responsible designs: 
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(1) classes such as Class A in Figure 1 should be Vabstruace 
classes; (2) every concrete descendent class should implement? 
the subclass responsible behavior; and, (3) carefully consider 
whether to include abstract classes which inherit from 
concrete classes implementing subclass responsible behaviors. 
b. Design Heuristics for Subclass Responsibility 

Should designers elect to organize behavior using 
subclass responsibility, the techniques of structured design 
can be used to structure solutions. The starting point is a 
class with one or more methods which are excessively large’, 
or not conceptually unified. Structured techniques can then 
be applied to decompose these methods. 

(1) Cohesion. - "Cohesion is the measure of the 
strength of functional relatedness of elements within a 
module." (Page-Jones, 1988, pg. 83) Modular elements’ are 
related (or associated) by virtue of some property they have 


in common. (Yourdon and Constantine, 1978) Included among 


"Either directly or through inheritance from another 
concrete class. 


‘The computer science literature is generally ambiguous 
about what constitutes an overly large module since the 
magnitude is influenced by notions of cohesion. However, half 
a page, about 30 lines of program statements in a high level 
language, has been offered as tolerable. (Page-Jones, 1988) 


"In the present context, modules refer to methods and 
elements refer to statements or groups of statements in a 
method. 
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these associative properties are the following: functional’, 
sequential’, communicational’, procedural”, temporal’’, 
logical’*®, and coincidental”. 

In the context of a class, a method is associated 
with a single form of behavior. Hence, functional cohesion 
should determine whether elements are bundled into a single 
method. Although sequential and communicational cohesion have 
also been supported as reasons for bundling elements into a 
Single module (Page-Jones, 1988), these are data-oriented 
associations which are incompatible with the behavioral 


underpinning to OO methods. In passing, it should be noted 


"Functional cohesion relates program elements that all 
contribute to the accomplishment of a single problem-related 
task. (Page-Jones, 1988) 


"Sequential cohesion involves activity such that output 
from one activity serves as input to the next activity. (Page- 
Jones, 1988) 


°Communicational cohesion relates elements which all 
share the same input, or contribute to the same output. (Page- 
Jones, 1988) 


“procedural cohesion relates activities associated by 
control flow. (Page-Jones, 1988) 


“Temporal cohesion involves activities related in time. 
(Page-Jones, 1988) 


*Logical cohesion relates activities of the same general 
category (for example, means of transport), the execution of 
which is determined from outside the module. (Page-Jones, 
1988) 


“Coincidental cohesion relates activities with no 
meaningful relationship to one another. (Page-Jones, 1988) 
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that the separate behaviors which are combined by these two 
forms of coheSion are not available to other methods or to 
descendent classes’*. The other forms of cohesion represent 
looser associations which should not be used to build methods. 
Consequently, elements that cannot be tied together through 
functional cohesion should be broken out as distinct methods. 

The problem remains, however, of elements within 
a functionally cohesive method which represent pieces of 
behavior which are conceptually the same’®, but which require 
different implementations depending upon the objects to which 
they are applied. These statements, not surprisingly, can be 
broken out uSing subclass responsibility 

{2) Coupling. Implicit in the notion of coneerer 
is the idea that large, uncohesive modules should be 
partitioned into smaller, conceptually unified modules. (Page- 
Jones, 1988) "It is vital that this partitioning should be 
carried out in a way that the modules are as independent as 
possible - this is the criterion of coupling...." (Page- 
Jones, 1988, pg. 57) Coupling in the OO environment has so 


far been described as a linkage established between two 





*These behaviors can be made available by duplicating 
definitions (i.e., defining methods which implement the same 
behavior). 


**Yourdon and Constantine describe these as "processing 
elements" in distinction to instructions or statements. 
{(Yourdon and Constantine, 1978, pg. 97) 
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classes on the basis of the knowledge possessed by one class 
of the other’s external and internal interfaces. Chapter 
V/Section A analyzes other forms of OO coupling, discussing 
aberrant forms of coupling in which classes possess direct 
knowledge of implementation details. 

It was previously suggested that subclass 
responsibility creates an undesirable coupling by requiring 
Subclass designers to understand in what contexts subclass 
responsible behaviors are invoked. This is evidenced by the 
fact that such behaviors have a specific role to play in 
completing the behavior expected of the calling method, and 
generally are not designed to fulfill independent behavioral 
duties (i.e., subclass responsible methods approximate what 
were termed auxiliary methods in Chapter II). 

Structured techniques usefully define two forms of 


coupling that should be avoided or minimized when designing 


subclass responsible relationships. First, Gata. couplang 
should be minimized. Data coupling is a linkage achieved 
through parameter passing. At issue is how many parameters 


are passed, what details are revealed by the parameters, and 
how the parameters are subsequently used (side effects). 
Designers should avoid passing large numbers of parameters, 
and should preserve encapsulation of structural details. 
Second, control coupling entails the passing of information 
intended to control the internal logic of the receiving 
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module. Control coupling requires that the calling method 
have knowledge about the details of subclass responsible 
behaviors. This has obvious implications for modifications 
effected on subclass responsible behaviors and should be 
avoided. Moreover, these complexities multiply as fan out’’ 
increases. 

(3) Factoring. "Factoring is the separation of a 
function contained as code in one module into a new module of 
its own” (Page-Jones,;@ 19°C mera. Loo, It is used to achieve 
one or more of the following (Page-Jones, 1988): reduce module 
size, achieve top-down design, avoid function duplication, 
separate work from management, generalize modules, simplify 
implementation. Note that factoring includes more than 
subclass responsibility. Hence, once a reason for pursuing 
factoring has been selected (reduce module size, generalize 
modules, etc.), structured techniques such as DFDs_ and 
structure charts can be used to examine methods and determine 
the merits of alternatives. 

Several issues need to be clarified, however, 


before factoring is attempted. First, a rationale must be 


“Fan out is a magnitude describing the number of modules 
subordinate to a higher level module. In the present context, 
fan out describes the number of descendent classes defining 
subclass responsible behavior for a particular invocation. 
Note that difficulties are even greater if more than one 
method in an ancestor class contains calls to subclass 
responsible behaviors. 


7A 


established. Top-down design of methods in a class is 
probably not a cogent reason for decomposition. Module size, 
of itself, is not a sufficient reason for breaking out 
behavior (1.e., large does not necessarily mean uncohesive). 
On the other hand, avoiding function duplication and 
generalizing methods are good reasons for decomposing methods. 
Second, once decomposition has been accomplished, 
decisions based upon OO considerations must be made about what 
to do with the results. Again, designers return to the 
requirement for formulating a methodology for allocating 
knowledge among classes. Matching behavior to objects in the 
problem has often been advanced in this thesis as one such 
criterion (1.e., responsibility driven analysis). 
Nevertheless, this rather facile solution requires substantial 
amplification. Should all the behaviors broken out by 
decomposition be retained in the class of the method from 
which they are decomposed? Should these behaviors be 
implemented as auxiliary methods? Should designers avail 
themselves of opportunities (offered by some OOPLs) to include 
behaviors as stand-alone functions and macros? Should non- 
behavioral considerations enter into the allocation of these 
behaviors in a hierarchy (for example, influencing binding 
time)? In short, structured techniques can be used to improve 
poorly designed methods, but this does not automatically 
translate to better designed classes and hierarchies. 
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Subclass responsibility appears to be a 
specialized instance of management/work separation. The 
ancestor class method decides some form of behavior needs to 
be invoked, descendent class methods actually implement the 
work. Management should be executed without knowledge about 
who (or, more accurately, what) performs the work. Designers 
can therefore employ structured techniques to isolate 
management/work relationships among functionally cohesive 
behaviors. Work can then be delegated to descendent classes 


for implementation. 
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V. PARADIGM CONFLICTS 


The OO philosophy concentrates thought about software 
development directly on those concepts which most forcefully 
impact the efficiency of the process - modularization, 
abstraction, information hiding, reusability, extendibility, 
and maintainability. It was noted in the previous chapters 
that the conduct of OOA, OOD, and OOP can vary widely 
depending upon the notations, methods, and concepts used. 00 
practitioners must consequently bear much of the burden for 
producing software that realizes the favorable properties 
comprehensively. This, in'turn, implies that programmers and 
designers should obtain a sound understanding of potential 
language mechanism conflicts and design tradeoffs. 

This chapter highlights OO language features which can 
potentially undermine the effective use of information hiding 
- the principle means by which long-term maintenance costs can 
be controlled. Specifically, attention is drawn to the 
encroachments on information hiding produced by inheritance’. 
Additionally, consideration is given to design criteria for 


employing composition over inheritance. 


‘The information hiding/inheritance conflict reflects 
design tradeoffs that must be made between information hiding 
and reusability. 
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A. ENCAPSULATION VULNERABILITIES 

A certain degree of economy enters into the design of OO 
software. Abstraction, information hiding, and reusability 
can be viewed as interdependent variables whose values 
designers collectively attempt to optimize. What constitutes 
a collective optimum, of course, is reserved to particular 
design philosophies. Nevertheless, there is a predisposition 
to consider information hiding as central in any solution to 
many software lifecycle problems’. 

Abstraction abets thinking that emphasizes essential 
properties over mundane details. From the outset, abstraction 
directs attention away from implementati n details. Hence, 
abstraction supports information hiding in the sense that the 
abstract conceptual approach promotes design organization 
which distinguishes property from detail. OO designs and 
programs exercise their abstract qualities through the 
respective class interfaces. Consequently, designers must 
understand OOPL mechanisms and vulnerabilities that circumvent 
or undermine the strict enforcement of communication 
controlled by interface. 

Inheritance increases code reuse. To the degree that 


inheritance mechanisms depart from interface enforcement, 





*Software engineering evolved during the late 1970's and 
early 1980’s in large part due to the explosion of software 
maintenance costs over the product life-cycle. (Booch, 1987) 
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reuse is achieved at a cost: the internal details of classes 
are exposed. Even in situations of strict interface 
enforcement, inheritance creates linkages among related 
classes that require careful attention when modifications are 
effected. These reservations with respect to inheritance are 
particularly prominent for complex applications involving 
highly developed class hierarchies. 
1. External Interface 
The external interface consists of those object 
features available to object users (see Chapter III on 
external clients). Poorly designed or inadequately enforced 
external interfaces can lead to a reduction in information 
Perding. 
a. Representation Access 
The primary purpose of encapsulation is to hide 
the structural details of objects. Limiting access to object 
variables to accessor methods allows designers a finer degree 
of control: (1) no access, read only access, or read/write 
access/update methods can be implemented; (2) users need not 
have any knowledge of variable types; (3) polymorphism can be 
exploited to construct conversion methods for handling 
variables’; and, (4) variables can be renamed, removed, or 
"An example would be an object which tracks location. 
The actual variables may be placed ina Cartesian grid. A 
polymorphic accessor method can be designed which uses either 
Cartesian or polar coordinants to set the value of the 
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reinterpreted’ without necessitating a recompilation of user 
code. (Snyder, 1986) 

OOPLs or designers may fail to insulate object 
variables from direct access/update in several ways. First, 
a language may not offer mechanisms to render the structural 
details private (i.e., they do not encapsulate). Second, 
though a language may provide an interface to access/update 
variables, it may not restrict the user to this interface. 
OOPLS may allow direct access/update by variable name (such as 
Simula), or may allow direct access/update through dot 
notation (such as Ctt+). Third, designers may write methods 
which contain embedded direct references to variables. In 
this case, users maintain an indirect capability for 
representation access. This leads to the curious, if not 
obvious, idea that objects must be protected from themselves! 

b. Creation and Initialization 

Some OOPLsS provide shortcuts for object creation 
and initialization which expose implementation details. 
(Micallef, 1988) Simula, which employs formal parameters, 


provides initialization by actual specification of values for 


Location variables. 


‘Variable modification/elimination, however, may require 
reviewing the implementation of the accessor methods to ensure 
that contracted behavior is maintained. This class method 
inspection necessity expands if other methods in the class can 
access variables directly (by name rather than through an 
accessor method). 
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the formal parameters; consequently, the "number, type and 
semantics of formal parameters are a part of the object’s 
external interface." (Micallef, 1988, pg. 18) Flavors allows 
initialization methods which directly use variable names as 
keywords. (Micallef, 1988) The preferred course to pursue in 
these instances is to separate object creation from object 
initialization such that variable access is limited to the 
body of initialization methods. (Micallef, 1988) Again, 
maximum information hiding is achieved when initialization 
methods must use accessor methods to assign values. 
c. Auxiliary Methods 
As noted in Chapter I1I/Section B, auxiliary 
methods are supporting operations, knowledge of which end 
users do not need. These methods should therefore not be part 
of the external interface. An OOPL should provide a mechanism 
to render these methods private to respective instantiations 
of the object. 
2. Internal Interface 
The internal interface consists of those ancestor 
features available to descendent classes by virtue of 
inheritance mechanisms. Some languages offer the capability 


of designating class features as private to instantiating 
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clients, but visible to inheriting clients’. (Micallef, 1988) 
As with poorly designed/enforced interfaces to instantiating 
clients, similarly weak interfaces to inheriting clients can 
expose implementation details. This subsection considers 
interface vulnerabilities. Subsequent sections discuss other 
facets of inheritance which pose problems for information 
hadang- 
a. Representation Access 
Access to superclass structural details should be 
limited to accessor/update methods for the same reasons as 
those outlined in the previous” section. Consequently, 
descendent classes should not _ be able» to direewiy 
access/update superclass variables by name or dot notation. 
This implies that superclass designers must cooperate by 
including the appropriate access/update methods. (Snyder, 
12966) 
b. Embedded Direct Access 
Methods which can potentially be inherited should 
utilize access/update methods for references to variables 
embedded in the methods; again, this results in reduced 
linkages thereby minimizing the effects oof variable 
modification/elimination. Hence, embedded direct access/ 
"Specifically, superclass features declared public or 


protected are visible to descendent classes. See Chapter 
II/Section C for more on inheritance. 
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update is dangerous to both superclasses and descendent 
Classes. 
C, — scene / This” Invocation 

Some OOPLs offer devices by which an object can 
directly invoke methods on itself. Smalltalk employs the word 
‘self’, "...a special variable representing the object which 
is the receiver of a message." (Smalltalk/v286 Tutorial 
Programming Handbook, 1988, pg.70) Similarly, Ct+ uses the 
word ‘this’, "a pointer to the object for which a member 
Mmm@erton 1s invoked...." (Stroustrup, 1987, pg. 137) Problems 
arise, however, if operations invoked through this device are 
redefined by a class or any of its descendants. (Snyder, 1986) 
An inherited method using ‘this’ (or ‘self’) may therefore 
invoke descendent class methods instead of the intended 
superclass method. 

Several options can address the problem: (1) 
designers of descendent classes can be aware of inherited 
method implementations - an undesirable violation of 
information hiding; (2) superclass designers can limit use of 
‘self’ or ‘this’ to refer to private methods; and, (3) some 
other language mechanism can be developed which allows an 
operation invocation to specify the appropriate superclass. 
Smalltalk provides a partial solution, allowing the word 


‘super’ to denote operation invocation on a= subclass’ 
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superclass®. Smalltalk/V286 Tutorial Programming Handbook, 


1988) Ct+t uses a scope resolution operator, ‘'::’’, to 


Specarleawmiy designate the source class for method 


implementation. Use of these devices ('’self’, ‘this’, or 
‘super’ ) unavoidably exposes inheriting classes Eke 
modification linkages. Designers should therefore carefully 


consider whether the convenience of these devices merits 
potential information hiding lesions. 
3. Name Conflicts 
Some analysts maintain that name conflicts "...are the 


root of the inheritance/encapsulation problem as it exists in 


most OOP languages." (Nelson, Moshell, a) i Orooji, 1991, pg. 
ZOD) Complications occur when descendent classes override 
ancestor variables. The risk is that overriding may happen 


‘This solution appears to push the problem upward one 
level in the class hierarchy. Suppose a subclass A invokes a 
superclass B method using ’super’. Superclass B itself employs 
a ‘super’ invocation to its superclass C. However, the ’super’ 
call in B to C is to a method which has been redefined in 
superclass B. The designer of subclass A has no way of knowing 
(barring examination of implementation code) whether the 
method he would intend to be invoked is in fact the one 
selected. This problem arises from the fact that methods using 
‘super’ can be inherited while ‘super’ only refers to a 
subclass’ immediate superclass. This solution also fails when 
multiple inheritance is used. (Snyder, 1986) 


"A superclass xX implementation of method Y could 
therefore be invoked by descendent class Z using the syntax 
X::¥. Direct naming, of course, links inheriting classes to 
the named class, exposing inheriting classes to modifications 
effected on the named class. (Stefik, 1986) 
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unintentionally - designers may be unaware of ancestor naming 
conventions because inherited variable names are hidden. 
Method name conflicts also present potential problems. ie 
appears, therefore, that subclass designers must possess 
knowledge about the internal details of ancestor classes. 
This section reviews name conflicts as they apply to single 
inheritance hierarchies. Multiple inheritance name conflicts 
are discussed in Subsection 5 of this section. 
a. Variable Name Conflicts 

As a class hierarchy expands, variable name 
conflicts can become more involved. In most conventional 
OOPLS, new variables with the same name as inherited variables 
are assumed to redefine variables which would otherwise have 
been inherited. (Nelson, Moshell, and Orooj1i, 1991) Designers 
consequently need to be able to distinguish viable 
redefinitions (overriding) from new variables. Hence, "...the 
designer of a class must know all that there is to know about 
the variables inherited from the superclass." (Nelson, 
Moshell, and Orooji, 1991, pg. 220) Note that this problem 
also applies to inherited methods with embedded references to 
variables which have subsequently been redefined. 

b. Method Name Conflicts 

Method name conflicts foster ambiguities similar 
to those associated with variable name conflicts. Overriding 
may unintentionally occur if subclasses define methods using 
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the same names as those of methods private to the parent 
Class. A subtle permutation of this problem is that there may 
be no way to control methods used by inherited methods. 
(Nelson, Moshell, Orooji, 1991) An inherited method may 
contain an embedded invocation to a method which has been 
redefined. Which implementation is subsequently used is 
language dependent’. (Nelson, Moshell, and Orooji, 1991) 
Cc. Name Conflict Remedies 
Several strategies can be employed to alleviate 
or eliminate unintended name conflicts. First, the OOPL 
environment may include a class hierarchy browser which 
permits investigation of inherited variable and method names’. 
"Nelson, Moshell, and Orooji (1991) raise another 
interesting (and amuSing) issue: every variable and method in 
an ancestor class may be overriden by the time a distant 
descendent class inherits. Consequently, a class can be an 
ancestor and yet not supply one inherited feature to the 
descendent class. Though the resolution of this is a matter of 
design philosophy, it raises questions as to the nature of the 
specialization which is being designed into the hierarchy. 
"This can be considered a violation of information 
ovalielaliaver: In particular, it may be the case that descendent 


Classes are designed by teams whose only intercommunication 
consists of knowledge about the external and internal 


interfaces. Nevertheless, hierarchy browsers are a common 
tool which facilitate a potentially simple solution to name 
conflicts. Information hiding should not be carried to such 


extremes that development is hindered more than assisted. This 
thought leads to another, larger issue. Though information 
hiding, abstraction, and modularization serve to promote 
reusability, the idea that reuse should be attempted without 
regard to inherited implementation details ought to be 
approached with some incredulity. An obvious example concerns 
code whose failure or aberrant behavior can produce life or 
system threatening results. 
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Designers are then free to make informed decisions about 
overriding. Second, multiple copies of inherited variables 
with the same name can be maintained, each accessible only by 
methods inherited through the internal interface’®. (Nelson, 
Moshell, and Orooji, 1991) Inherited methods avert name 
femmiicts by continuing to function under the interface 
environment that existed in the respective superclass. Third, 
the logic of inheritance can be restricted to extension only. 
Bamguage facilities can be structured which catch and disallow 
name conflicts. This solution, though feasible, would overly 
constrict the inheritance process. Moreover, it would 
disallow overriding, a mechanism that is sometimes central to 
specialization guiding the hierarchy construction. 
4A. Hierarchy/Lattice Modification Problems 

Chapter I1I/Section C reviewed several strategies for 
shaping class hierarchies. Modifications to a class hierarchy 
potentially rupture the underlying hierarchy Logic, 
invalidating the contracts which exist between superclass and 


subclasses. Information hiding cannot completely insulate 


Note that the authors have defined the internal 
interface to consist "...of those methods defined locally for 
the class and all of the methods in the external interface of 
each superclass (but not each ancestor) of the class." 
(Nelson, Moshell, and Orooji, 1991, pg. 223) Name conflicts 
are avoided by attaching the superclass name to inherited 
methods. The authors use the term "enheritance" to describe 
this form of encapsulated inheritance. (Nelson, Moshell, and 
Miaeeg1, L991, pg. 223) 
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classes related through inheritance from the adverse impacts 
produced by these modifications. Consequently, OO programmers 
need to understand these linkages before attempting to modify 
class hierarchies. This caveat applies especially during the 
maintenance phase of the software life cycle’’. 
a. Inheritance Visibility 

Inheritance visibility refers to "...whether or 
not the use of inheritance itself should be part of the 
internal interface (of the class or the objects). In other 
words, should clients of a class (necessarily) be able to tell 
whether or not a class is defined using inheritance?" (Snyder, 
1986, pp. 405405) At issue is whether inheritance should 
remain strictly a mechanism for code reuse, or whether it 
should enforce particular inheritance strategies (e.g., 
specialization and/or subtyping). Snyder (1986) and Micallef 
(1988) contend that inheritance visibility undermines 
information hiding and reduces programming flexibility. 

(1) Excluding operations. "Most object-oriented 
languages promote inheritance as a technique Or 


specialization and do not permit a class to ‘exclude’ an 


“An approach to this problem from a different perspective 
argues that program-based testing of proven code needs to be 
reexamined when class hierarchies are modified. (Perry and 
Kaiser, 1990) Though the discussion is technical, the authors 
note various linkages produced by inheritance that require 
retesting of code in both modified and inheriting classes when 
code is modified. 
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inherited operation from its own internal interface." (Snyder, 
iese6, pg. 41) The idea expressed is that specialization 
requires that ancestor features be inherited. Hence, a chain 
of transitive relationships is set up in a hierarchy. A 
modification such as redefining the superclasses for an 
ancestor class severely impacts descendent classes built on 
the expectation of inherited features from the now absent 
superclasses. Hence, superclass modifications must account 
for inheritance relationships by maintaining a_e stable 
interface. 

(2) Subtyping. It was noted in Chapter 
Ii/Section C that some OOPLS identify subtyping with 
inheritance to facilitate static type-checking. "If subtyping 
rules are based on inheritance, then reimplementing a class 
such that its position in the inheritance graph is changed can 
make clients of that class type-incorrect, even if the 
external interface of the class remains the same." (Micallef, 
1988, pg. 25) For example, suppose that class Y is a subclass 
of class X, and that class Y is redefined to be a subclass of 
Class Z (and not of class X). Objects of class X can no 
longer be substituted for objects of class Y. Consequently, 
reusability is reduced and source code may need to be 
rewritten. 

(3) Remedies. Inheritance troubles traceable to 
subtyping mechanisms (in which types are identified with 
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classes) cannot be ameliorated’* - removing ancestor classes 
will always invalidate existing substitutions based upon type 
relationships (barring coercion). Clearly, such modifications 
should occur during the initial design (or rapid prototyping) 
phase of development, and not during the maintenance phase of 
mature software products’. 

Two methods are available for reducing inheritance 
linkages. First, modifications should preserve a stable 
interface. This leads to the notion that once a class moves 
into its ‘'’post-production phases’, its interface should be 
closed (except for extensions)”™. Second, inheritance 
visibility should be limited to aée:abclass’ immediate 


superclasses, and inherited methods should only invoke other 


inherited methods’**®. (Nelson, Moshell, and Orooji, 1991) The 


“Tt has been noted that subtyping problems could be 
handled by separating the type hierarchy from the inheritance 
hierarchy. (Micallef, 1988) Furthermore, "...a formal 
semantic specification of behavior is needed to be able to 
correctly do behavioral subtyping." (Micallef, 1988, pg. 27) 
That is, some standard needs to be agreed upon to relieve 
programmers of the burden for selecting subtyping rules, 
thereby automating subtyping decisions. 


Note that elimination of any ancestor class from which 
features are inherited poses the same problem - regardless of 
the logic guiding hierarchy construction. 


“It is possible to ‘eliminate’ methods by coding null 
implementations. This is a dangerous practice, however, that 
can produce deleterious results. 


“Basically, this solution amounts to renaming the 
offending methods. 
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latter technique prevents subclass methods from ‘reaching up’ 
a hierarchy to ancestor variables or methods which have been 
overridden by superclasses. In this manner, inheriting 
classes are concerned only with inherited behavior, and not 
with inherited implementations. (Nelson, Moshell, and Orooji, 
tO 1 ) 
5. Multiple Inheritance 

All of the inheritance problems considered above also 
apply to multiple inheritance. Ineeaistametron to single 
inheritance, however, solutions are far more complex - 
individual OOPLs can create inheritance graphs that are 
unknown and undesired. As an example, CLOS (Keene, 1989) 
employs specificity rules for determining which specifiers for 
individual slots will be inherited. Consequently, the 
definition of a slot may represent an amalgam of specifiers 
inherited from different classes. Designers have _ to 
investigate every superclass to determine the actual form of 
inheritance. This example returns to the larger problem 
addressed in Chapter 2/Section C: what precedence rules does 
an OOPL apply for determining what is inherited and for 
resolving name conflicts? "The way this conflict is resolved 
in some languages produces different results if the 
inheritance graph is changed, even though the external 
interfaces of the objects remain the same." (Micallef, 1988, 


pg. 26) 
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For languages which permit MI, precedence rules 
determine the shape of inheritance and resolve name conflicts. 
Generally, such rules either flatten MI graphs into linear 
chains by introducing a total ordering among the classes and 
then applying rules for single inheritance’®, or directly 
locate in the MI graph inheritable variables and methods’’. 
(Stefik and Bobrow, 1986) 

Linear solutions will produce results which depend 
upon the decision criteria adopted for arriving at a total 
ordering. A risk is that these criteria result in chains 
which do not reflect designer intentions’®. (Stefik and Bobrow, 
1986) Hence, name conflict resolution (and inheritance in 
general) may not follow designer intentions. This compels the 
designer to investigate the implementations of actually 
inherited features to ensure consistency of purpose. 

Graph-oriented solutions require the development of 
graph traversal strategies to implement inheritance. 


Additional rules must be developed to handle name conflicts 


Such strategies are titled "linear solutions." (Stefik 
and Bobrow, 1986, pg. 43) The authors note that Flavors and 
CommonLoops use this strategy. 


Such strategies are titled "graph-oriented solutions." 
(Stefik and Bobrow, 1986, pg. 42) The authors note that 
Trellis/Owl and extended Smalltalk use this strategy. 


"For example, a chain may be established in which an 
immediate superclass is separated from a subclass by other 
classes which redefine methods in the superclass. 
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and inheritance from a common ancestor (non-tree graphs). 
Name conflict resolution possibilities include the following: 
(1) do not allow name conflicts; (2) force the subclass to 
implement variables/methods which override any name conflicts; 
and, (3) allow inheritance of all conflicting methods’®. Non- 
tree inheritance can be handled by limiting inheritance to one 
set of inherited variables/methods from common ancestors, or 
multiple sets (depending on the number of paths from an 
ancestor to descendent class). The problem with graph- 
oriented solutions is that inheritance is exposed to 
modifications in the class hierarchy (i.e., inheritance 
Pest oOility) . Furthermore, designers must understand how 
potential ancestors implement methods (where name conflicts 
exist) to decide upon which inheritance strategy to pursue. 
The solutions to MI problems are the same as those 
advanced in the previous section: a stable interface and 
inheritance limited to immediate superclasses. Common 
ancestor problems are probably best handled by matching the 


number of instance variable sets to inheritance paths’*®. Name 


“Such strategies require some rules for deciding how the 


inherited methods will be invoked. Possibilities include 
language determined orderings, and designer determined 
orderings. 


°This eliminates a situation in which multiply inherited 
methods from a common ancestor repeatedly update a single set 
of instance variables also inherited from the same ancestor. 
(Stefik and Bobrow, 1986) 
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conflicts can be handled as before - tagging each such method 
with its superclass name and restricting its visibility to the 
interface of its class. 
6. Design Recommendations 

Designers should endeavor 1 Lo: understand the 
complications introduced by inheritance and minimize its 
detrimental aspects early in the design phase. Aside from 
general problems attributable to inheritance, problems 
specific to individual OO languages should also be thoroughly 
understood. We now offer the following design recommendations 
for guiding inheritance decisions: 

General Hierarchy Prescriptions - 


oAvoid constructing hierarchies which include 
multiple paths to common ancestors. 


oWhen utilizing multiple inheritance, minimize the 
number of immediate superclasses. 


oIf the OOPL being used allows user defined 
precedence ordering**’ for MI, avoid modifying 
superclass orderings unless absolutely necessary. 


°Reduce the effects of modifications by limiting 
the depth of hierarchy graphs to three or four 
levels. 


oAlways restrict variable access/update to methods 
in the appropriate interface. 


**Many OOPLs (such as Smalltalk) determine a precedence 
order based upon the textual order in which superclasses are 
listed in the definition of a subclass. Note that this exposes 
such subclasses to potentially unintended side-effects should 
the list be reordered. 
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oMinimize the number of methods in both the 
external and internal interfaces. 


oH cho.g G)d eal e. Pub Ere, protected, and private 
mechanisms, if available in the OOPL being used. 
If not available, attempt to directly design and 
enforce these facilities into the class 
hierarchy. 


oMinimize the use of self-referential devices such 
aS Seite ancowetini1 so 


oMinimize/avoid use of devices which allow direct 
invocations of variables/methods which are not 
part of the internal interface (e.g., dot 
notation). 


oThoroughly understand ancestor class visibility 
in the OOPL being used. If prominent, carefully 
consider the consequences of changes to the graph 
structure. 


oMaintain stable class interfaces. 


°oMinimize the number of embedded method 
PivoCat Ons - 


Name Conflicts - 


oWhen possible, employ configuration management 


techniques Wich liiewemanLag amcontlicts. 9 Lt 
available, exploit class browsers to uncover name 
eontlvets . 


°Carefully investigate the resolution mechanisms 
employed by the OOPL being used. Design classes 
and modifications with these mechanisms in mind. 
For many languages, this unavoidably requires 
implementation visibility of the interface. 


oIf possible, inherit all variables for which 
name conflicts exist, using some syntactical 
device such as tagging with the superclass 
name to differentiate such variables. Limit 


interactions with these variables to methods 
inherited from the corresponding superclass. 


°oUltimately, OOPLS will have to be designed 
which can search inheritance graphs for name 
coniiiega, and make decisions based upon 
semantic properties of the affected methods and 
inheriting subclasses. 

B. COMPOSITION AND INHERITANCE 

A fundamental task of OOD is to determine the behavior and 
structure of objects (as abstracted into a class). Often, 
designers must consider whether structures and behaviors 
should be inherited or realized through composition’*. This 
task inevitably requires investigating the nature of the 
relationships which exist between objects. At first glance, 
the decision appears to be a simple distinction between ’ kind- 
of’ and ’part-of’ relationships. However in many situations 
the complexity of object relationships vitiates quick 
determination of appropriate relationships, and therefore 
complicates inheritance/composition choices. 

The real difficulty in dealing with composite objects is 
that the OO design process focuses on classes and class 
hierarchies in a manner which emphasizes the independence of 
the abstractions being described. This conceptual approach 
does not directly lend itself to the analysis of composition 
relationships which can exist between objects of classes in 
different hierarchies. Designers must therefore carefully 
detail the entire nexus of object interconnections that 
formulate a composite object. A critical matter in “eis 

**Recall that inheritance reflects relationships between 
classes while composition reflects relationships between 


objects. 
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regard is determining whether an object’s behavior is modified 
when it forms 'part-of’ a higher level object (i.e., has a 
role to play in some form of collective behavior). Designers 
must address where these constraints are to be effected, and 
what policy to pursue if an object has more than one role to 
Peaye(2-¢., 1S 'part~of’ more than one object). 

This section reviews composition, advances criteria for 
recognizing composition relationships, draws out the 
[Pier tecations of using composition versus inheritance, 
illustrates inheritance/composition tradeoffs by presenting 
solutions to a simple design problem using three different 
OOPLS, and considers to what degree composite objects should 
parallel the details of real-world objects. 

1. Composition Reviewed 

Chapter II/Section D introduced the idea of 
composition, noting several properties of composition 
relationships. The concept is further analyzed in this 
subsection; particular attention is directed to subtleties 


which complicate the design of composite objects. 


Semposition 9 "2..1S a tightly coupled form of 
association*? with some extra semantics." (Rumbaugh, 1991, pg. 
S17) Rumbaugh (1991) discusses several properties of 


composition which distinguish it as a specialized form of 


*7Association is an abstraction used to group objects from 
several independent classes. (Elmasri and Navathe, 1989) 
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association: (1) the relationship is transitive’**; (2) the 
relationship is antisymmetric’’; and, (3) properties (state 
values and operations) of the whole can propagate to the 
part. 

That properties propagate raises several interesting 
issues. First, the form of interconnectedness induced by 
composition requires analyzing the existential dependency of 
contained objects. Specifically, should an object which is 
part of another object manifest a separate identity? This has 
implications for creation and destruction operations. It also 
portends the possibility On conf lvetang interobject 
interactions. Technically, the problem can be viewed as one 
in which the variables which make up an object are themselves 
objects’’, or are pointers to objects’*®. (Nelson, 1990) Not 
surprisingly, pointer referencing also allows’ contained 
objects to be shared by more than one containing object. 


Second, subobjects and dependent objects most likely will have 


*“For example, A is part of B, and B is part of C implies 
that A is part of C. 


*°A is part of B implies that B is not part of A. 


7"An example would be that the speed of an aircraft 
propagates to the parts which compose the aircraft - the 
wheels, engines, wings, etc. 


‘Nelson terms these "dependent objects." (Nelson, 1990, 
pg- 5) Dependent objects do not exist apart from the objects 
they are a part of. 


7@Nelson terms these "subob jects." (Nelson, 1990, PGE 
5) Subobjects do exist apart from the objects they are part 
Of 
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some properties in common with the object of which they are a 


amet” . This follows naturally from the idea of property 
propagation. However, as suggested above, subobjects may be 
‘part-of’ more than one object - creating a requirement to 


insulate subobjects against potentially conflicting state 
changes. Zuplaere Eransitivity implies that these 
considerations flow through to all objects at whatever level 
in a composition hierarchy’. Complex determinations must be 
made as to what level properties propagate to. Finally, 
antisymmetry implies that properties do not necessarily 
propagate to higher levels in a composition hierarchy. 
Another facet of composition requiring attention is 
the cardinality relationship between containing objects and 
sub/dependent objects. Possibilities include the following: 
Aggregation can be fixed, variable, or recursive. A fixed 
aggregate has a fixed structure; the number and types of 


subparts are predefined”. A variable aggregate has a finite 
number of levels, but the number of parts may vary’. A 


°This possibility reflects a design consideration - 
should propagated properties be maintained by contained 
objects, or can these properties be assumed to be maintained 
by the containing object? Solutions to this question may be 
influenced by whether or not contained objects exist 
independent of the containing object. 


°°A composition hierarchy can be conceived of as a tree 
depicting composition relationships. Such a hierarchy starts 
with the highest level object, and moves downward to 
successively more granular levels of detail. 


"For example, a golf club always has one clubhead, one 
shaft, and one grip. 


For example, an academic course may consist of a single 
professor and several students. However, there may be a 
variable number of students per course (1.¢€., a one-to-many 
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recursive aggregate contains, directly or indirect!) en 

instance of the same kind of aggregate; the number of 

potential levels is unlimited*’. (Rumbaugh, 1991, pg. 59) 
Fixed aggregates are the easiest to understand and design. 
Variable aggregates, however, pose interesting problems for 
reusability. How does one design a class for composite 
objects such that objects can be instantiated with variable 
numbers of parts? Must each variation be modeled by a 
distinct class (using inheritance) ? This problem will be 
investigated in Subsection 4. 

Finally, a distinction is sometimes drawn between objects 
that are composed of other objects (a car) and objects that 
contain other objects (an array of integers). (Wirfs-Brock, 
Wilkerson, and Wiener, 1990) Though both relationships can be 
modeled as composition, containment is a much looser form of 
association. It is often the case that a container does not 
need to interact with the elements it holds. In other cases, 
interactions do occur”™*. Frequently, containment relationships 
involve a design choice between employing composite objects or 


instantiations of parameterized classes (see Chapter 


relationship prevails). 


“For example, a computer program may consist of blocks 
containing compound statements which, in turn, contain other 
blocks. (Rumbaugh, 1991) Recursive composition should be 
avoided in most cases as there is the potential for an 
infinite recursion in which an object calls upon itself to 
formulate its definition. 


“For example, a hash table may need to ask an element for 
its hash code before adding the element to the table. (Wirfs- 
Brock, Wilkerson, and Wiener, 1990) 
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II/Section B). Containers that do not interact with their 
parts are probably best modeled using parameterized classes. 
This clearly identifies the limited behavioral connections 
Derween the container and the objects it holds. 
2. Recognizing Composition 

several keys to composition have already been 
emecussed: (1) ‘part-of’ relationships; (2) propagation of 
properties/operations; (3) cardinality considerations; and, 
(4) interobject behavioral constraints*®*. Other facts of a 
problem situation may also suggest that composition fits a 
particular object to object relationship. These include the 
following: (1) collective instantiation and destruction; (2) 


delegation of responsibilities from the whole to parts; 


(Wirfs-Brock, Wilkerson, and Wiener, 1990) and, (3) service 
iaeaary °° . 
3. Composition or Inheritance? 


Though individual facts may indicate that composition 
is the appropriate design choice, the possibility always 


exists for modeling such relationships using inheritance®’. In 


Composite objects "...describe for instantiation a 
m_iemly connected set of objects...." (Stefik and Bobrow, 1986, 
pg- 58) 


**This rather vague notion marks the fact that parts do 
not act independently, but rather are controlled by the 
unifying purpose of the whole object. This would serve to 
distinguish, for instance, a clock and a radio which happen to 
be collocated, from a clock-radio. 


"In particular, multiple inheritance can be used as an 
alternative to composition. 
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many situations, it is not clear whether composition or 
inheritance should be used (the design problem considered in 
the following subsection is an example). Hence, it is worth 
considering in what respects the consequences of selecting one 
over the other differ. 

Inheritance is a class relationship, whereas 
composition is an instance association; differences in the 
nature and mechanics of the two relationships start from this 
fundamental distinction®. First, the hrerarchweal) strucmeme 
which serves to define a class through inheritance establishes 
the identity of a single object. Composition, on the other 
hand, involves a relationship between ok jects with separate 
identities”. 

Second, composition strictly limits visibility ongene 
part of the containing object to the external interfaces of 
its parts. Inheritance allows a finer degree of visibility 
which generally entails greater accessibility through the 
internal interface. 

Third, inherited behavior is visible to other objects 
to the extent that it is included in the external interface. 
The behavior of objects serving as parts, on the other hand, 


is not visible to other objects - the containing object 


**Composition can be thought of as a form of part 
inheritance while inheritance can be viewed as behavioral 
inheritance. (Nelson, 1990) 


This holds regardless of whether the part is a dependent 
object or a subobject. 
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mediates any such interactions”. 


Fourth, “behavior can be easier to reuse as a 
component than by inheriting it." (Johnson and Foote, 1991, 
pg. 124) As an example, it is easier to add an extra 


scrollbar to a window as a component, than it is to multiply 
inherit scrollbars. (Johnson and Foote, 1991) The idea is 
that inheritance used in this manner may require undesirable 
changes to the behavior established by ancestor classes. 

Fifth, as noted in the previous section, inheritance 
potentially exposes information hiding to compromise. 
Composition does increase the coupling between objects; 
nevertheless, information hiding is not violated since all 
interactions are managed through the respective external 
interfaces. 

Finally, specialization was previously identified as 
the principle strategy for structuring class hierarchies (see 
Chapter II/Section C). Hence, an appropriate question to ask 
when contemplating inheritance/composition choices is whether 
or not a resulting subclass can be said to be a specialization 
of the class(es) from which it inherits. For example, "it is 
not valid to define a class Car that inherits from Body, 
Frame, Wheels, and similar classes, since a car is not a 
wheel." (Nierstrasz, 1989, pg. 8) A different perspective on 


specialization is to consider the substitution possibilities 


“This distinction is reduced to the extent that an OOPL 
permits manipulations by pointer operations. 
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discussed in Chapter II. Inheritance should not be used if 
Substituting a subclass object for a superclass object does 
not satisfy applicable compatibility requirements (for 
example, a car cannot be substituted for a wheel in any 
meaningful way). 

A. The Clock Radio Problem 

It is instructive to underline the ramifications of 
selecting composition or inheritance by investigating the 
solution to a sample design problem. This section considers 
designs for a clock radio in three different OCOPLS ise 
Smalltalk, and CLOS. Separate solutions for each OOPL, one 
using inheritance and the other using composition, are 
illustrated and compared. 

Although a major theme of this thesis is the advocacy 
of OOA/OOD practices which enhance the entire OOP process, 
independent of any particular OOPL, it must be conceded that 
at this point in the evolution of OOPLs language selection 
does impact design opportunities. Hence, the three OOPLs are 
also used to illustrate language dependent differences between 
composition and inheritance. 

a. Problem Statement 

The clock radio is a common household device which 
consists of a clock and a radio. It manifests many of the 
properties listed above for recognizing composition: (1) the 
clock and the radio are parts of a clock radio, (2) (properese. 


such as location and power propagate from the whole to the 
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mares; (3) a clock-radio could conceivably contain more than 
one clock, or more than one radio; and, (4) behavioral 
constraints not ordinarily associated with separate clocks and 
radios are possible (for example, a clock controlled timer can 
turn the radio off). Figure 2 displays the responsibilities 
that rudimentary OOA might reveal as germane to a 
etock radio. State information represents knowledge that a 
Sock radio maintains about itself. Services define the 
behavior of a clock_radio. The list is obviously not 
complete, but for present purposes can be accepted as a 
standard upon which permutations may be structured. Note that 
fegure 2 is not a class definition in any OOPL, but rather a 
listing of behaviors and state information. Hence, 
distinctions such as instance and class variables are not 


required. 













State information | 
present location ereyenloy elibeva ie cbate 
power on Giigek alaim tame 








Services 


set time volume increase 
set Clock alarm volume decrease 
set radio alarm select channel 

play am radio on 

play fm 


Figure 2: Clock Radio Responsibilities 
In the subsections which follow analysis will 


focus on three classes: efectrc Clock, beso), and 


Sec radio.) JO Simplify discussion, the electric clock and 
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radio classes are not placed into hiverarchies® (1 .e 7a 
detailed design in which suitable variables and methods are 
elevated to abstract classes is not performed). Figuvew. 
illustrates the inheritance class relationships, and Figure 4 


shows the composition object relationships which will be 


modeled. 


Class electric clock Class Radio | 





Figure 3: Inheritance Class Relationships 











Object cloeckyzodic 


object electric clock 
object radio 





Figure 4: Composition Object Relationships 

The implementations contained in Appendices A, B, 
and C are not intended to demonstrate a comprehensive, usable 
solution. In particular, error handling is not provided. For 
the dynamically typed languages (Smalltalk and CLOS), no 
effort was made to enforce type checking. Casual observation 
will also reveal that instance variables are directly accessed 
in most of the implementations. This was done to reduce and 


Simplify the code. 
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Cit ISeamavbracd OOPL, exected om the foundation of 
the C programming language. The principal building blocks 
include objects, message passing, classes, and inheritance 
hierarchies. C++ is a strongly typed language in which 
classes implement abstract data types. The language does 
provide for virtual classes and for public, protected, private 
visibility declarations. Multiple inheritance hierarchies can 
also be built. 


Appendix A contains the Ct+ solution to the 


Clock radio problem. The code successfully compiled and 
tested on a Borland Turbo ca eompilerm (Borland 
International, 1990) Section A contains the declarations for 


the various classes in the problem, including classes for 
types time and position. Following the class name is a list 
of type declarations (for example, x _y posit) and variable 
names (for example, radio location). Due to the absence of any 
Meorbality declaration, the default visibility for the 
variables is private. Note that variables such as size and 
color could also be included. These were omitted since 
location and power already serve the purpose of demonstrating 
variables whose value propagate from the whole. 

All methods are given public visibility; 
consequently, they belong to both the external and the 
internal interfaces. ‘Void’ indicates that a method does not 


return a value. Finally, a method with the same name as the 
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class name is a constructor. Constructors set aside space in 
memory when an object instance is created and can be used for 
initializing instance variables**. Similarly, a method with 
the class name and a tilde (~) prefixed is a destructor. An 
example of a destructor is given in electric clock class: 
Destructors, which can only be called by the compiler, are 
used to undo side effects such as changes to global variables. 
(Eckel, 1989) Generally, programmer-defined destructors are 
not included; instead, a default destructor supplied by the 
compiler is used. (Eckel, ae) 
(1) Inheritance. Class clock radio in AppemGre: 
A/Section A illustrates the design of a clock radio class 
using multiple inheritance. The public declarations in the 
first line indicate that the internal and external interfaces 
of superclasses are inherited as designed (variable/method 
visibilities remain unchanged). Sections B through G provide 
implementations of the methods for the respective classes. 
Observe that a more fully developed clock design would access 
operating system clock functions to provide actual time 
behavior. This was not done to simplify the problem. Note the 
efficiency by which the behavior of the class is managed 
through multiple inheritance. Simple extension is used to 
complete the behavior of the class, and reusability is 
exploited. 
"In this case, it is assumed that the construceos 
initializes the electric-clock to a powered state and the 
alarm to off (1.e., power on := True, andvalarm On [erates 
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Several other features merit attention. First, 
Soer radio iS a subtype of both an electric clock and a 
radio, and can consequently substitute for either one. This 
follows from the identification of class and type hierarchies 
enforced by Ctt. 

Second, although not present in this design, it is 


conceivable that name conflicts could exist for the location 


variable and the power method. C++ resolves this through 
resolution operators. Name conflicts must always’ be 
considered when using inheritance. Unless the design 


strategies noted in the previous section are followed, 
preventing and resolving name conflicts inevitably requires 
knowledge about superclass details. 

Third, while C++ allows a class to be inherited 
indirectly more than once, a given superclass can only be 
directly inherited once. This poses cardinality problems. 
Pesentially, a clock radio Class based on inheritance must be 
redesigned each time a different combination of clocks or 
radios is desired. 

Finally, constructor and destructor methods cannot 
be inherited. (Atkinson and Atkinson, 1991) Unless compiler 
supplied default constructors and destructors are preferred, 
subclass methods must explicitly account for ancestor 
Eoenstructors and destructors. This fact assumes importance 


during hierarchy design as it can impact object initialization 
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and free memory management**. (Atkinson and Atkinson, 1991) 

(2) Composition. The composite clock radio class 
in Appendix A/Section A uses composition to reuse 
electric clock and radio behavior. Several features alludedua.e 
above are immediately apparent. First, the external interface 
of the clock_radio is the only conduit to contained objects 
for objects using a clock_radio. Hence, greater design effort 
is required to engineer the desired behavior. Note that the 
external interface to the composite clock radio class 
essentially duplicates the electric (Clo: and radio 
interfaces. Although this promotes information hiding, it 
also translates to a degree of inefficient CPU use since it 
amounts to providing methods whose sole purpose is to function 
as a protective layer (i. eu7 doubles function "lea 
processing). 

Second, name conflicts are not a problem. If all 
interactions are forced through the external interfaces of the 
electric clock and the radio respectively, name Cont iimems 
Gannee ,OCeuLr- 

Third, the facility with which extra radios or 
electric clocks could be added as constituent parts is 
evident: simply declare new variables of the required types. 
Nonetheless, the implementation of clock _radio methods which 
control interactions among the various parts would have to be 

“Tt has been recommended that virtual constructors and 
destructors be declared in superclasses to ease the design 
burden on subclasses. (Atkinson and Atkinson, 1991) 
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modified to account for the new structure of the entire 
object. The same logical changes have to be made when using 
inheritance. In this respect there is no advantage to using 
composition. However, it still remains much easier to create 
multiple parts using composition. 

BO eis te lar as is the case with inheritance, 
constructors and destructors must be specifically accounted 
mer . This can be done comparatively easily using 
imiteialization lists. (Atkinson and Atkinson, 1991) In 
fees tanction tO inheritance, asenrding which 
constructors/destructors to include is simple: those of 
contained objects (this assumes no inheritance). Multiple 
inheritance, on the other hand, can produce complicated 
scenarios in which sequencing of construction/destruction is 
important. Composition only requires that contained objects 
be created prior to the containing object. 

Fifth, a strategy needs to be adopted for handling 
properties which propagate. Both electric clock and radio 
objects contain instance variables for location. Designers 
must decide whether or not to include a location instance 
mommable £Or the clock radio, and whether or not to propagate 
i5eaci101 assignments to both”™the™electric cYock and the radio 
Parts. Property propagation creates familiar data update 


problems (ensuring consistent information is maintained), and 
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constitutes unnecessary data duplication‘’*®. Notice also that 
property propagation also implies some knowledge about the 
details of part objects**. In this solution, responsibility 
for maintaining location and power information is retained by 
the clock radio. Changes are propagated to its respeceume 
parts. Note, however, that this responsibility is directly 
inherited when inheritance is used. Consequently, a location 
instance variable was not created for clock radios formecme, 
inheritance. This appears to be a situation in which it would 
be useful to design electric clock or radio subclasses which 
exclude the location instance variable. However, all the 
methods in the affected class would hav to be searched to 
eliminate direct references to this variable or calls to 
accessor methods. 

Finally, a clock radio is no Tonger a subtypemeen 
an electric clock ior (aaaEocsior Hence, substituting a 


Clock radio for either of its two parts would generateman 


“A significant difference should be noted between 


inheritance and composition. In languages which do not 
provide visibility control mechanisms like those found in Ct+, 
the external interface includes inherited methods. Hence, 


messages can be sent to descendent objects that invoke 
inherited methods which return state information relating to 
propagated properties from instance variables declared in 
ancestor classes. Designers must ensure that all such state 
information is current and consistent since such calls can not 
be precluded in these kinds of languages. Smalltalk is an 
example of one such OOPL. 


**All of these considerations also apply to multiple 


inheritance in which more than one superclass maintains the 
same state information. 
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error message at compile time 
c. Smalltalk Solution 

Smalltalk* is a dynamically typed OOPL featuring 
objects, classes, metaclasses, and single inheritance’®. 
Messages can be sent to instances (instance methods), or to 
classes (class methods)*’. Class definitions include instance 
variables and class variables. A singular quality of 
Smalltalk is its comprehensive environment: programming and 
design are all accomplished within the confines of the 
Smalltalk system of disk and hierarchy browsers employing 
extensive windowing and menu controls. 

Another useful feature (ene the Smalltalk 
environment is its library of predefined classes. All classes 
(predefined and user defined) comprise one large hierarchy 
descended from the root class Object. New classes are defined 
by filling in the appropriate information in system supplied 
templates. New classes must be descended from a superclass in 


the hierarchy. 


“Several variants of the Smalltalk language are 
commercially available. These dialects manifest widely 
varying capabilities. The present discussion draws upon 
Digitalk’s Smalltalk/V286. (Smalltalk/V286, 1988) 


*“Other versions of Smalltalk do provide for multiple 
inheritance. (Stefik and Bobrow, 1986) However, the use of 
multiple inheritance in these versions "...is not used much or 
Paecitutcionalized.” (Stefik and Bobrow, 1986, pg. 49) 


*"Classes are treated as objects in Smalltalk; hence, the 
need for metaclasses. 
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(1) Inheritance. Though the requirement to place 
new classes into the inheritance hierarchy facilitates shaping 
a common protocol, the absence of stand-alone classes reduces 
the flexibility with which designers can construct classes - 
it slows development to the extent that designers must 
consider potentially lengthy inheritance chains. Visibility 
of variables to other objects is limited to accessor methods 
provided by the class. All variables and methods are 
inherited; subclasses can add new variables or methods, and 
can override superclass methods. 

Appendix B/Section A displays completed templates 
for the various classes in the clock _radio problem. Sections 
B through G display method implemtations. The code 
successfully interpreted and tested on Digitalk’s 
Smalltalk/v286 interpreter. The electric clock class inherits 
from the radio class, while the radio class is assumed to have 
the electric device class (not depicted) as its "superceta 
Variables are defined without type declarations and the class 
interface is not included in the template. Methods are 
defined by selecting the new method menu option; hence, a 
method interface and its implementation are defined 
simultaneously. Fach class has the same methods as those 
previously identified for the corresponding Ct+ class. 

Given that Smalltalk/V286 allows only single 
inheritance, one of the two superclasses must be inherited 


from the other in order to replace multiple inheritance. This 
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is not a desirable state because instances of the inheriting 
class must exhibit behavior of the superclass; hence, for 
example, a pure radio could not be instantiated should the 
ia-tonme) class inherit from the et eeateme Oc elass. 
Additionally, such inheritance establishes hierarchies that do 
not truly reflect any SOGt of specialization: an 
@teetric ciock is not a specialization of a radio. Designers 
should be very deliberate and consistent in selecting criteria 
for structuring the single Smalltalk hierarchy. Problems 
arise when the same class serves multiple roles: template for 
inheritance, part object template, and user object template’. 
Immediately, all name conflict problems previously 
discussed reappear. Note that Smalltalk treats conflicting 
instance variable names as an error. Note also that a 
foe radio Can be safely substituted for an electric clock or 
a radio using this form of inheritance. Similarly, an 
pee = tC Clock Can be safely substituted for a radio since it 
inherits behavior from the radio. class. The latter 
possibility is not desirable for reasons presented earlier. 
Inherited instance variables are accessible by 
name in Smalltalk. This poses a problem for designers of 


inherited classes such as SUGGS ea6l5l@): A Silexels  icteve be 


*"A user object (my term) is a semantic notion describing 
objects which interact with other objects through respective 
external interfaces while maintaining independent identities 
that do not involve composition. The idea is drawn from Booch 
who distinguishes containing relationships from using 
relationships. (Booch, 1991) 
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designed through inheritance is conceived of as a single, 
unified object. Given that Smalltalk is a dynamically typed 
language, a designer must have knowledge of superclass method 
implementations in order to avoid inconsistent variable typing 
(especially if overriding inherited variables or methods). 
Conflicts can be avoided by using only inherited methods to 
access/modify inherited variables. However, this then 
requires that ancestor classes be designed to account for 
descendent class (actual and potential) requirements*”. This 
sort of design thinking is adequate for specialization 
hierarchies, but is exceedingly difficult for hierarchies 
replacing multiple inheritance. 

As is the case with C++, inheritance in Smalltalk 
is entirely inadequate for designing clock radios with 
multiple clocks or radios. The limitation is made apparent by 
the fact that only single inheritance is allowed. 

Finally, designers should design constructor and 
initializer class methods which account for ancestor classes. 
The safe approach is to design initializer methods which issue 
super calls to the superclass initializer; thereby, avoiding 
any typing errors. Smalltalk automatically supports garbage 
collection; hence, destructors are not required. 

(2) Composition. Appendix B/Section A displays 
the Smalltalk definition for a composite clleck radie) clace. 

“That is, an ancestor class must provide descendent 
classes with all the methods they require to access/modify 
inherited variables. 
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instance variables for a clock and a radio are defined. All 
interactions with the objects these variables point to are 
managed through the objects’ interfaces. Clearly, this 
approach to designing a clock radio is much cleaner than a 
solution based upon ersatz multiple inheritance. 

Again, the template in Section A illustrates that 
only variable names have been defined. It has been argued 
that the absence of a type-system in Smalltalk renders it 
impossible for a compiler to optimize Smalltalk code. 
(Johnson, 1988) The thought can be taken a step further by 
asserting that the absence of a type-system also severely 
undermines the type continuity that should prevail among the 
parts of an object. Designers must assume responsibility for 
ensuring that conceptually inappropriate type assignments or 
method selections do not occur at run-time. Rivas S;. Sot 
course, a difficult task at best. However, in the absence of 
a type-system that can be used by a compiler’®, designers 
should enforce type continuity of parts through the following 
Qe lb) Clock radio object creation should create and 
Miatialize parts according to their appropriate class; (2) 


state changes stored in instance variables should be effected 


*°Johnson describes an effort at introducing a type-system 


to Smalltalk that is "...type-safe, handles polymorphic 
procedures and parameterized types, and can be used by an 
fomemizing Compiler.” (Johnson, 1988, pg. 317) 
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by accessor methods which perform type checking”; and, (3) 
messages sent to a part are type correct for the part, or for 
any ancestors of a part”. 

Multiple clocks or radios can be added by defining 
specialized subclasses of class clock_radio. Clock_radio 
class methods which organize part behavior will need to be 
extended to accommodate new structures. 

d. CLOS Solution 

CLOS is a hybrid OOPL built upon the Common Lisp 
programming language. (Koschmann, 1990) It features objects, 
classes, generic functions, and methods. Classes consist of 
local and shared slots (instance anc class variables). 
Programmers attach methods to generic functions through method 


definition®?, and users invoke methods by calling the 


“IMost Smalltalk instance variables contain pointers 
referring to objects. (Smalltalk/v286, 1988) Some instance 
variables contain 8 bit bytes representing elementary data 
values. (Smalltalk/vV286, 1988) Instance variable types can 
easily be changed by assigning pointers to different objects 
(l.e., avoid aliasing). 


“Johnson states that "a message-send is type-correct if 
it is type-correct for each possible object type of the 
receiver." (Johnson, 1988, pg. 318) He describes the process 
of unification which establishes that a "procedure call is 
type-correct if there is some assignment of types to type 
variables (of the method) that makes the types of the 
arguments be in the types of the parameters; the return type 
of the procedure call is the return type of the definition of 
the method with all the type variables replaced by the 
assignment to them." (Johnson, 1988, pg. 318) 


Generic functions constitute the interface to a set of 
methods. Each method has the same name as the generic function 
it implements, and the same number of parameters. The generic 
dispatcher selects appropriate methods on the basis of type 
correspondence between message arguments and method 
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appropriate generic function. (Keene, 1989) CLOS provides for 
multiple inheritance in which both slots and methods are 
inherited. The order in which superclasses are listed in a 
class definition determines precedence for handling problems 
such as name conflicts. 

CLOS is a dynamically typed OOPL. (Koschmann, 
1990) Slots can be typed using the :type specifier. However, 
many commercially available CLOS interpreters do not enforce 
such slot typing. (Keene, 1989) 

Appendix C/Section A illustrates the definitions 
epee Various Classes in the clock radio problem. Most of 
the slots in the clock radio problem are assigned default 
values using the -:initform specifier. This prevents any slots 
from being unbound. Sections B through G display the various 
method implementations. The code successfully interpreted and 
tested using an Allegro CL interpreter (Sun4 version). 

(1) Inheritance. As is the case with C++, the use 
Swmuttiple inheritance in CLOS to build a clock radio class 
Peeeecemely erticient. A clock radio class can be descended 
Peomechese two superclasses as illustrated by the clock radio 
class in Section A. Again, the order in which superclasses 


are listed determines the precedence which the generic 


parameters. In the absence of a corresponding generic 
mane t 10nN for a method definition (defmethod), Ci.OS 
automatically creates the generic function from the defmethod. 
The CLOS implementation to the clock radio problem assumes 
this automatic generic function building; hence, only 
defmethods are illustrated. 


se, 


dispatcher will use in selecting methods for generic function 
calls. Consequently, this form of precedence exposes 
implementations to the modification errors described in 
Chapter V/Section A. All of the reservations expressed with 
respect to a solution using inheritance in C++ also apply to 
a solution in CLOS*™*. Additionally, dynamic typing presents 
the same problem as that noted for Smalltalk - designers need 
to carefully monitor what information is maintained by slots”. 

(2) Composition. The composite clock rad1ojetae. 
demonstates composition in CLOS. Essentially, a pointer to 
the desired part of object is created (using the (buviae 
function make-instance) and assigned to the slot variable. As 
in Smalitalk, it is required that slots be created and 
initialized to the appropriate types. Observe that the parts 
have been given names (for example, clock one) in anticipation 
of instances which have multiple parts. This is not good 
programming style in that users must maintain information 
about the parts of an object, and can directly refer to these 
parts. Although direct naming is not required for a 


“4“CLOS contains a variety of mechanisms for defining and 
organizing behavior: mixins, multi-methods, before methods, 


after methods, around methods, and individual methods. 
Developers can exercise tight control over method structure, 
and generic dispatching. However, these opportunities often 


result in designs which are highly individualized, tightly 
coupled, and susceptible to modification errors. 


°*>CLOS allows slots to be directly accessed using the setf 
function Interfaces which include this function directly 
expose data structures and expose slots to dynamic type 
Changes. In short, designers must guarantee that slots are in 
fact encapsulated. 
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eieek radio consisting of only one clock and one radio, such 
naming appears to be unavoidable for this kind of object when 
maeger mumbers of clocks or radios are included. Clock radio 
methods can be defined which organize the interactions between 
Clock one and radio one. As before, cardinality can be 
handled by defining composite clock radio subclasses which add 
new parts and override relevant controller methods when 
necessary. 

An important difference from Smalltalk is that 
slots can be directly accessed/modified using the built-in 
functions slot-value and setf. CLOS provides a slot specifier 
:accessor which automatically creates a generic function for 
reading and writing a slot. The accessor so created forms 
part of the external interface. Nevertheless, slots are not 
encapsulated by accessors. CLOS does not provide any 
mechanisms for enforcing the notion of a private slot. 
Consequently, composite objects in CLOS do not truly form an 
intermediate layer between users and parts. 

5. Composition Granularity 
Another interesting problem with respect to 
composition is the granularity of detail. An example may 
Poise tO demonstrate the problem. Bache loci class, Can be 
designed such that it includes one electric plug/cord 
combination. Shou dsmelock sradi om@consisting of multiple 
Clocks therefore have multiple plugs and cords? The problem 


arises from the fact that classes can serve both as templates 
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for composition objects and as templates for independent 
objects. 

The solution to this problem lies in reconsidering the 
fundamental nature and purposes of OOA and OOD. Guiding 00 
development is the goal of specifying and organizing the 
behavioral properties of objects in the application domain. 
Although aspects of physical structure enter into designs, 
these only occur as required to fulfill behavioral 
requirements. Similarly, variables are included only as 
required to preserve state information. The primary focus, it 
should be reemphasized, is on behavior. Hence, a clock is 
either powered or it is not. This is state information which 
should be included in a design. Though a plug/cord form a 
conduit for powering a clock, they really do not have any 
behavioral responsibilities that other objects may interact 
with, and they cannot be associated with any state 
preservation duties. Consequently, a design for a clock class 
should not include variables for plugs and cords. 

The clock radio problem demonstrated, however, that 
different classes may maintain identical state information. 
Hence, multiple instances of the same piece of information are 
maintained when either inheritance or composition is used. As 
suggested in the clock _ radio discussion, this is an 
unavoidable problem, excepting exclusion, which requires some 
sort of data consistency/duplication policy on the part of 


designers. 
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The same problem reappears in another context. It has 
previously been noted that both in the context of system 
design and in composition design properties/responsibilities 
are delegated to constituent elements. It is not improbable 
that delegated properties/responsibilities may not be needed 
in new design problems; EUS, reducing reusability 
opportunities and forcing considerable redesign. Expanding 
upon the notion of moving common behavior upwards in class 
hierarchies (see Chapter III), classes at the higher levels in 
a hierarchy should provide common behaviors in the most 
general sense: behavior generalized to the class of objects as 
they might occur in any application. Hence, a clock class 
would provide behavior expected of any clock. Subclasses can 
then be used to extend behavior to suit particular system or 
composite object requirements. What forms a generalized 
formulation of behavior applicable to a class of objects is a 


knowledge problem that must be arrived at during OOA. 


Bae 


VI. CONCLUSIONS 


A. SUGGESTIONS FOR FUTURE RESEARCH 
1. Specialization 

Chapter II introduced the notion of specialization. 
This concept figures importantly in controlling’ the 
development of inheritance hierarchies. Nonetheless, a 
formalized definition of specialization needs to be 
researched. Sueb a definition should distinguish 
specialization from subtyping, and should explore the 
interrelationships between the two con«2pts when building 
inheritance hierarchies. 

2. Reusability 

The various design strategies discussed in Chapter III 
advanced criteria for recognizing and organizing the 
relationships among the elements of a problem. These 
strategies provided criteria for the explicit organization of 
behavior in designed classes. However, the immediate focus of 
these approaches generally fell upon the current problem. 
Research needs to be directed toward uncovering criteria for 
organizing knowledge in a manner that facilitates reusability 
for potential applications. What level of generality should 
be placed into abstract classes? At what level in a hierarchy 
should abstract classes give way to concrete classes? Should 
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consideration of potential subclasses influence the design of 
concrete classes? What criteria should determine which 
behaviors define a class of objects, and how do these criteria 
influence reusability? 
3. Knowledge Allocation 

It was suggested in Chapter V that structured 
techniques can be used to improve the implementation of OO 
methods. However, recommendations for accomplishing this were 
scrupulously avoided. Research needs to be directed at 
uncovering criteria for using the results of such techniques 
memrimporove OO design. In particular, it may prove fruitful to 
investigate whether criteria other than behavioral 
correspondence (behavior to real-world object) should 
influence the allocation of behaviors in a hierarchy. 

4. Functional Decomposition 

Chapter IV analyzed the design practice of subclass 
responsibility as a subset of techniques descended from 
functional decomposition. Heuristics were suggested for 
designing subclass responsible behaviors. Further 
investigation should be conducted into the potential 
vulnerabilities of hierarchy designs which use functional 
decomposition techniques to uncover and organize subclass 


responsible behaviors. In particular, the ways in which 
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hierarchy modifications can expose such designs to unexpected 
errors merits research. 
B. CONCLUSIONS 

The OO paradigm represents a new perspective on the 
practice of developing software. It arrives with a complement 
of concepts, tools, and theories which permits developers to 
organize their thinking in a fashion which parallels the 
manner in which humans develop and compose knowledge about the 
real world. As experience with the OO approach progresses, 
the realization grows that the greatest gains occur in the 
areas of analysis and design: intelligent, coherent 
application of OO concepts during these phases of development 
substantially reduces the. effort and costs associated with 
programming and maintenance. 

Though the OO paradigm promises much, the absence of 
conceptual continuity and standardization has so far resulted 
in a multiplicity of distinctly diverse OOPLs and development 
Strategies. This thesis has attempted to formulate an 
understanding of fundamental OO concepts (Chapter II) and the 
tradeoffs involved in applying those concepts (Chapter IV). 
Such a foundation should serve to facilitate analysis/design 
practices (Chapter III and Chapter IV) which realize the many 
benefits attributable to OO development (Chapter I). 

Particular attention has been drawn to inheritance as a 
vehicle for organizing knowledge. Inheritance smartly 
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applied is a powerful mechanism for reusability. It is the 
position of the author that among the strategies which can be 
employed to construct inheritance hierarchies, the safest and 
conceptually most appropriate course lies in identifying class 
hierarchies with type hierarchies. This allows the compiler 
to perform optimization operations, and forces some form of 
semantic consistency/structure on the inheritance hierarchy. 
In this setting, developers also need to converge on a 
Peacticable definition of specialization. 

While inheritance promotes programming economy through 
reusability, the single most important aspect to OOP (or any 
programming methodology) is information hiding. Information 
hiding shields designers from their own mistakes while 
concomitantly reducing the effort expended in uncovering and 
correcting mistakes. Designers utilizing inheritance must 
understand and account for inheritance/information hiding 
Preadeoffs. Negligence in this regard can only iead to long- 


run maintenance difficulties and attendant cost increases. 
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APPENDIX A. C++ CODE 


C++ CLASS DEFINITIONS 


#ifndef CLKRAD HPP 
#define CLKRAD HPP 
const am = 0; //define switch values 
const fm 
const true 
const false 
Const “OLE 
const on 


ll 
RFP OOrFRF SO 


e ™e “e 


f 


class “2y poste 
Ime oe; //Cartesian reference system 
abigne ae 
Pubiae- 
x y posit (int x pos = 0, int y pos = 0) {x = x _ pos; 
Y = =yeros) 
x VY posi operalor] Gana osm Ee 
void display position () ; he 


class time { 
int hours; //military time 
int minutes; 
int seconds; 


joke oy Aer 
time (){hours = 0; minutes = 0; seconds = 0Q;} 
time (int hrs, int mins, int secs) {hours = hrs; 
minutes = mins; 
seconds = secs; } 
void change time (time); 
time operator=(time) ; 
void display time(); }; 
class radio { 
x y posit radio location; //can be implemented many 
Genie radio powered; //true equals powered 
int radio on; 
float fm station; 
float amestatwon, 
int am fm switch; 
float volume level; 
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muDliac: 
radio (xy posit) ; 
void change radio position (x_y posit); 
void power radio(); 
void remove radio power (); 
void turn radio on (); 
void ec all radio Pore 
void increase _volume OG; 
void decrease volume (); 
void select am(); 
void select fm(); 
woresehoot wanestat one (t loa) 
void select fm station (float) ; 
void display radio on Orr Siediae ae, 
Peta d1 splay © “volume level (); 
void display _ am channel (); 
Mord display _ fm channel (); 
void display radio position (); 
de 


class electric clock { 
Sy POS 1e clock mLCeat1 on, 


BE Tate clock powered; 

eT te clock alarm; 

time current time; 

time clock alarm time; 
public: 7 = 


elecerie clock (xy posit) ; 

void change me lock tpos te ren (x y posit); 
void power clock (); 

sacl remove clock power (); 

void reset clock time (time) ; 

void clock alarm on (); 

void clock alarm off (); 

void set clock alarm time (time) ; 
void display clock alarm time (); 
void display clock time (); 

void display _clock position (); 
pooeerd Gaclock 7); 


We 


Zo 


class Gilieeck rade 


ihe 
time 
ante 


public 
clock _radio(x_y posit); 


teen el 
void 
void 
void 
vOLd 
VOLd 
void 
void 


VO ld 


Jae 


Publwe cadie- 
clock radio powered; 
radio alarm time; 
radio alarm; 


pub ive electric elec 


change clk rad position(x y posit); 
power clock radio(); 

remove clock _radio_ power (); 

set radio alarm een Geers 1) eg 
radio_ alarm on, 

radio alarm enme ly 

display_ radio alarm ONC PE Ese arc 
display _ radon alarm _ time 
display | clockm radio position 


()? 
() ; 
(); 


class Gompostee elock gr acuemy 


electric clock Gloc. some, jf Dake Bon. 
radio radio one; // pact 
x y posit comp _ elk _rad position; 
int comp clk rad powered; 
ete comp radio alarm; 
time COMp _ radio alarm time; 

pub ier 


composite clock radio 


void 
void 
void 
void 
void 
void 
void 
WO 1c 
void 
void 
void 
void 
void 
void 
void 
void 
Oa 
Jao peel 


(x _y posit); 
power comp _ - clock _radio(); 

Lemove comes clock _radio_power (); 
change _ comp clk me Ade posit em (x wy Poste): 
turn_comp_ radio on ()? 

Curn comp) radiogot.: aja, 
increase comp radio volume (); 
decrease comp radio volume (); 
select aligseal) chm mica 
select fm station (float); 
select am (); 

select fm (); 


reset _comp | clock time(time t); 
COmMp _ clock alarm on (); 

COMp _ clock _ _alarm_ OLE 3G, 

COMp _ -radio alarm on (); 

comp radio —alarm_ OLE ye, 

set _radio alarm time (time); 

set _ _ comp _ elle cham alarm_ time (time); 
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Veta display comp Clock alarm tame —() - 
void display comp clock time (); 

void display comp radio on off state (); 
void display comp radio volume level Oe 
void display comp radio am channel (); 
void display comp radio fm channel ()e; 


ie 


#endif CLKRAD HPP 
X Y¥ POSIT CLASS METHODS 


my posit x y posit::operator=(x y posit xy) 
return *this; 


Perc y posit: :display position () 
{ 


Seite sec NY POSIEILON 1a 8x3! <Cex ay. << y 
Ce OS tae 
} 


TIME CLASS METHODS 


void time::change time (time t) 
{ 
if ((hours >= 0) && (hours <= 24)) 
Nnours = t.hours; 
else 
hours = 0; 


if ((minutes >= 0) && (minutes <= 60)) 
minutes = t.minutes; 

else 
minutes = 0; 


if ((seconds >= 0) && (seconds <= 60)) 
seconds = t.seconds; 

else 
seconds = 0; 


he) AL 


time time::operator=(time t) 
{ 

change time (t); 

return *this; 


} 


void time::display time () 

{ 
cout << "The time is " << hours << ":" << minutes << 
us" << seconds <n 


} 


RADIO CLASS METHODS 


radio: :radio(* y posit Untreraloe seer) 
radio location(initial position) 


{ 


radio powered = false; 
radio on = off; 
Ces ae tom = 88.0; 
am station = 55.0; 
am fm switch = fm; 
volume level =: 12 OF 


void radio::change radio | pos tt oni, oe. = 
new position) 

{ 
radio location = new position; 


} 


void radio: :power radio() 


{ 


radio powered = true; 


} 


Vou radio::remove radio power () 
{ 

radio powered = false; 

radio on ene. 


} 


ee 


hold radlo::turn radio on () 
{ 
radio on = on; 


} 


Mec cagdlo., Cur radio off {) 


{ 


radio powered = false; 


} 


moid radio::increase volume () 


{ 
} 


Wome Leven <= 97 0; 


void radio::decrease volume () 


{ 
} 


volume level c= Oo: 


vo1d radio::select am() 


{ 
am fm switch = am; 


} 


void radio::select fm() 


{ 
} 


am fm switch = fm; 


void radio::select am station (float channel) 
{ 
Himvclrd sentry — false; 
Wene( i vatid entry) 
{ 
1£f ((55.0 <= channel) && (channel <= 160.0) ) 
{ 
Waeelanenme Ly — Eruc; 
aneseatl1on — channel; 


} 


3 


else 
{ 
cout << "Invalid entry, try again between 55 and 
60> kKhze en 
cin >> channel; 
} //endif 
} //endwhile 


void radio: :selece  Pyseacl One (eo aed acme) 


{ 
aie ieelibatel Gioneten, = false; 
while s(1valtodientxy ) 


1£f ((88.0 <= channel) && (channel<= 108.0)) 
{ 


pigs Wibalrc Faye sey ere SaibKS 5 
fm station = channel; 
} 
else 


{ 
cout << "Invalid entry, try again between 88 and 
108 mhz\n"; 
cin >> channel; 
} //endi£ 
} //endwhile 


void radio: -display radio (onmot f gata comm) 
{ 
cout << "The radio is) "<< radiiegome ae fe me 


} 


vold nadie] -daspilay ovo lume sete. een) 


{ 
cout << "The radio volume is " << VOFume where 
ee Man Nts 


134 


void radio::display am channel () 


{ 
} 


oe Dewan stare lon V8) 9 ameceation << \n"; 


void radio::display fm channel () 


{ 


CUM oowenie im Station is ~ << fm station << ee 


} 


wolderad1o: ;display radio position ({) 
{ 
mace “hOCat1 on. display position () 7 


} 


ELECTRIC CLOCK CLASS METHODS 


Pie eemalececlock: electric clock (xy posit 
mirerats position) ; Clock location (initial position), 
SuErent tame(), clock alarm time () 


{ 
clock powered = false; 
clock alarm = off; 


} 


ocdmeltect ric Clock: : Change clock position (x_y posit 
new position) 
{ 


Glee locaton — Mew poster on, 


} 


motemeleceri1c clock: -power clock () 


{ 


clock powered = true; 


} 


void CC eenremehock,.Lremove Clock power () 


{ 


clock powered = false; 


} 


LES es: 


acon mel etectric Clec= 


{ 


current time = t; 


} 


void electric clock: 


{ 


clock alarm = on; 


} 


VO 1c electr#eze! oe): 


{ 


Clock alariea =e. i, 


} 


void eleocer tegelock:: 


{ 


clock _ alarm time 


} 


;reset  Cclocarime(jeame oe 


:Clock alarm on() 


Clee alaznnger = (|) 


set clock alarm -:ime(time t} 


cy 


void electric clock: :displayvelock jalarnuaeame ae 


{ 


clock_alarm_time.display time (); 


} 


void electric clock: ; display (clock a iwemsy 


{ 


Current Came da gp layered), 


} 


void electric. clock: :displaygeleciepoct tommy 


clock _location.display position (); 


} 


LOG 
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CLOCK RADIO CLASS METHODS 


elec wradie::clock radio (x y posit initial position) 


macdvo(amitial, position), elect ialem ene x 
(anitial position), radio alarm time (), 
{ 
elock radio powered = false; 
radio alarm = off; 


} 


yore clock (radio::change cik rad position (x y posit 
new position) 

{ 
ehangewe lock positron (new postt1en) 7; 
ehangewradiO position (new position); 


metdeelock radio::;power clock radio () 


{ 
Bower clock {); 
Bowen radio () > 


} 


void clock radio::remove clock radio power () 


{ 
remove clock power (); 
remove radio power (); 


} 


void Glocker adie | set erod.O ual anime ame (time t) 


{ 
} 


radio alarm time = t; 


Mera clock radio::radio_alarm_on {) 


{ 
} 


radio alarm aor 


eS / 


void clock radio: : radio alax meee) 


{ 


radio alarm = Of f- 


} 


void clock_radio::display radio alarm on off state () 


{ 


cout << "The radio alarm is “ << radio alarm <<) aaa 


} 


void clock radio: :disp¥ay Sradronatacne mene) 
{ 
radio alarmytime: display (eames 


} 


void clock _radio::display clock radio position {) 
{ 

display clock position (); 
} 


COMPOSITE CLOCK RADIO CLASS METHODS 


composite clock radio::composite clock radio (x y posit 
initial position) :; clock one (initial posture 
radio one (initial position), comp radio alarm Uanem® 
{ 
comp clk rad powered = off; //false equals off 
comp radio alarm = off; //false equals off 


} 


void composite clock radio; :- power compuclock radscume 
{ 

comp cik rad powerea = eerne, 

radio one.power radio (); 

Clock one. power velock 709 


} 


void composite clock radio::remove comp clock radio power () 
{ 

comp Clik stad pewered et alece, 

radio one.power radio (); 

clock_one.power clock (); } 


ILSy8) 


void composite clock _radio::change comp clk rad position 
(x _y posit new position) 

{ 
comp clk rad _ position = new position; 
Picatomone change radio Position (new position) ; 
ellockyone- change clock positicn (new position) ; 


ore composite Clock radio: iturn comp radio on () 


{ 


Pad OvOne. turn radio om (); 


} 


feta Composite clock radio::turn comp radio off () 


{ 


MAGEOPOne.GUurn radio off () ; 


} 


ota composite clock radio::inerease comp radio volume () 


{ 


radio one.increase volume (); 


} 


Pera Composite clock radio::decrease comp radio volume () 


{ 


radio one.decrease volume (); 


} 


[21a Composite clock radio::select_am_ station (float 
channel) 


{ 
} 


BAIGrowome. selece am station (channel); 


(etosconpostte Clock radio::select £m station (float 
channel) 


{ 
} 


BadtOmone. celect Em station (channel) ; 


void Compositege loca agar. 


{ 


radio vene. select fate. @ 


} 


void composite clock radio: 


{ 


radio One sekecr Miran, 


} 


void composite elock nade: 


{ 


clock One] reser ce toca 


} 


void composite clock radio 


{ 


clock one.clock alarm on 


} 


void composite clock radio 


{ 


clock_one.clock alarm of 


} 


void composite clock radic: 


{ 
comp radio alarm = on; 


} 


vold composite jeloek radie: 


{ 
comp radio alarm = off; 


} 


void composite clock radio: 


{ 
comp radio alarm time = 


} 


Se lec mami) 


shone Si), 


-reset comp clock time (timeme 


me (tC) ; 


::comp clock alarm _on () 


(); 


::comp clock_alarm_ off () 


LC, 


:comp radio alarm on() 


~COmp radio vo larmnoL. 


:set radio alarm time (time t) 


ee, 
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void composite clock _radio::set comp clock alarm time 
(time t) 
{ 


erect one-set cillock alarm time (t); 


} 


mee composite clock radio::display comp clock alarm time () 
{ 


euccr one.display clock alarm time (); 


} 


void composite clock radio::display comp clock time () 


{ 


meek eone-display clock time (); 


} 


ferma Composite clock radio::display comp radio on off state () 
{ 
madi@ One.Cdisplay radio on off state (); 


} 


Bemencomeosite Clock radio::display comp radio volume level () 


{ 


maeto One-Gisplay volume level (); 


} 


mora composite clock radio::display comp radio am channel () 


{ 


Padi1o one.display am channel (); 


} 


fee COMposite Clock radio::display comp radio fm channel () 
{ 


PatrOomwoncearsplay fm Channel ({); 


} 
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APPENDIX B. SMALLTALK CODE 


SMALLTALK CLASS DEFINITIONS 


object subclass: #XyPosit 
instanceVariableNames: ' x y ’ 
ClassVariableNames: ‘’ 
POclDicr tomar Les 


object subclass: #SimpleTime 
instanceVariableNames: ’ hours minutes seconds ’ 
classVariableNames: '’ 
poolDictionaries: '' 


object subclass: #Radio 


instanceVariableNames: ' radioLocation radioPowered 
radioOn fmStation amStation amfmSwitch 
volumeLevel '’ 


classVariableNames: /'’ 
poolDictionaries: ‘'’ 


radio subclass: #ElectricClock 
instanceVariableNames: ’ clockPowered clockAlarm 
currentTime clockAlarmTime '’ 
classVariableNames: ’’ 
poolDictionaries: ‘’ 


electric clock subclass: #ClockRadio 
instanceVariableNames: '’ clockRadioPowered 
radioAlarmTime radioAlarm ’ 
classVariableNames: ’’ 
poolDictionaries: '' 


object subclass: #CompositeClockRadio 
instanceVariableNames: '’ clockOne radioOne 
compClockRadioPosition compClockRadioPowered 
radioAlarmTime radioAlarm '’ 
classVariableNames: ’’ 
poolDictionaries: ‘'' 
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B. xXYPOSIT CLASS METHODS 


Seex: XPOS SELEY: ypos 


x 2:= Xp. 
yo s YP 
displayPosition 
impuiEOoueput char | 
input := Readstream on: /The XY position is K:% Y:&’. 
output := Writestream on: String new. 
[input atEnd] 
whileFalse: [(char := input next) = $% 


Perrine. (4 prime On? (omMtput | 
ifFalse: [(char = $&) 
1ET rues y oprineon ys sOurEpUE | 
ifFalse: [output nextPut: char]]]. 
“output contents 


C. SIMPLETIME CLASS METHODS 


changeTimeHours: hrs minutes: mins seconds: secs 


hours := hrs. 
minutes := mins. 
seconds := secs. 
displayTime 
fenput “output char | 
input := Readstream on: ‘The time iS %:&:#’. 
output := Writestream on: String new. 
[input atEnd] 
whileFalse: [(char := input next) = $% 


feerue: [hours printOn: output] 
ifFalse: [(char = $&) 
iPflrue>. (mMainaces PraneOn: OuLpuL| 
ifFalse: [{(char = $#) 
ifTrue: [seconds printOn: output] 
ifFalse: [output nextPut: char]]]] 
“output contents 


D. RADIO CLASS METHODS 


Parcralize: initialPosition 


radioLocation := XyPosit new. 
radioLocation := initialPosition. 
radioPowered = ‘false’. 
radiooOn = ‘off’. 
fmStation -= 88.0. 
amStation = 55.0. 
amfmSwitch = 'am’. 
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volumeLevel =) Leo 


changeRadioPosition: newPosition 


radioLocation := newPosition. 
powerRadio 
radioPowered :=""true’. 


removeRadioPower 
radioPowered := ‘false’. 


turnRadioon 
(radioPowered = ‘true’ ) 
1fTrue: [radioOn := ’on’]. 


turnRadiooff 
radvoOn. —. cL 


increaseVolume 
volumeLevel := volumeLevel * 2.0. 


decreaseVolume 
volumeLevel <= volumeLevel * O75. 


selectAm 
amfmSwitch 


Il 
) 
a 


selectFm 
amfmSwitch 


T 
rh 
ad 


selectAmStation: channel 
(channel >= 55.0 and: [channel <= 160.0]) 
1fTrue: f[amStation := channel]. 


selectFmStation: channel 
(channel >= 88.0 and: [channel <= 108.0]) 
1fTrue: [fmStation := channel]. 


displayRadioOnoOffState 
“radioon 


displayVolumeLevel 
“volumeLevel 


displayAmChannel 
“amStation 


display fm channel 
“EmStation 
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display radio position 
“radioLocation displayPosition. 


ELECTRICCLOCK CLASS METHODS 


initialize: intialPosition 
Supe=s Initialize: anitialPosition. 


clockPowered = ‘false’. 

clockAlarm as © | Sen Aa 

currentTime = time new. 

currentTime >= changeTimeHours: 
seconds: 0 

clockAlarmTime := time new. 

elock alarmTime := changeTimeHours: 


seconds: 0 


changeClockPosition: newPosition 


RadioLocation := newPosition. 
powerClock 
clockPowered := ‘true’. 


removeClockPower 
clockPowered 


‘false’. 


resetClockTime: newTime 


currentTime := newTime. 
clockAlarmOn 

clockAlarm := ‘on’. 
clockAlarmOfft 

eclockAvarm <= “off. 


setClockAlarmTime: newAlarmTime 
clockAlarmTime := newAlarmTime. 


displayClockAlarmTime 
“clockAlarmTime displayTime. 


displayClockTime 
“currentTime displayTime. 


display clock position 
“radioLocation displayPosition. 


O minutes: 


0 minutes: 


0 


0 


CLOCKRADIO CLASS METHODS 


initialize: initialPosi tom 
super initialize: initialPosition. 
clockRadioPowered := ’false’. 
radioAlarmTime := SimpleTime new. 
radioAlarmTime changeTimeHours: 0 minutes: 0 
seconds: 0 
radioAlarm := ‘off’. 


changeClkRadPosition: newPosition 
self changeRadioPosition: newPosition. 


powerClockRadio 
clockRadioPowered := ‘true’. 
self powerRadio. 
self powerClock. 


removeClockRadioPower 
clockRadioPowered := ’false’. 
self removeRadioPower. 
self removeClockPower. 
self turnRadioofet. 


setRadioAlarmTime: newTime 


radioAlarmTime := newTime. 
radioAlarmOn 

radioAlarm := ‘on’. 
radioAlarmOfE 

radioAlarm *="°“otfe 


displayRadioAlarmOnOffState 
“radioAlarm 


displayRadioAlarmTime 
“radioAlarmTime displayTime. 


displayClockRadioPosition 
“self displayRadioPosition. 


COMPOSITECLOCKRADIO CLASS METHODS 


initialize: initialPosition 


radioOne := Radio new. 
radioOne initialize: initialPosition. 
clockOne := ElectricClock new. 


clockOne initialize: initialPosition. 
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compClockRadioPosition XyPosit new. 
compClockRadioPosition iiatial Posse ven: 
compClockRadioPowered := ’false’. 
radioAlarmTime := SimpleTime new. 
radioAlarmTime changeTimeHours: 0 minutes: 
seconds: 0 
radioAlarm := ‘off’. 


powerCompClockRadio 
clockOne powerClock. 
radioOne powerRadio. 
compClockRadioPowered := ‘true’. 


removeCompClockRadioPower 
clockOne removeClockPower. 
radioOne removeRadioPower. 
compClockRadioPowered := ‘false’. 


changeCompClkRadPosition: newPosition 
ClockOne changeClockPosition: newPosition. 
radioOne changeRadioPosition: newPosition. 
compClockRadioPosition := newPosition. 


turnCompRadioon 
radioOne turnRadioon. 


turnCompRadiooff 
radioOne turnRadiooff. 


increaseCompRadioVolume 
radioOne increaseVolume. 


decreaseCompRadiovolume 
radioOne decreaseVolume. 


selectAmStation: channel 
radioOne selectAmStation: channel. 


ee eee ens € ieon channel 
radioOne selectFmStation: channel. 


selectAm 
radioOne selectAm. 


selectFm 
radioOne selectfm. 


resetCompClockTime: newTime 
clockOne resetClockTime: newTime. 
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compClockAlarmOn 
clockOne clockAlarmoOn. 


compClockAlarmOfft 
clockOne clockAlarmOff. 


compRadioAlarmOn 


radioAlarm =: = "one 
compRadioAlarmOff 
radioAlarm <+) Ofel.. 


setRadioAlarmTime: newTime 
radioAlarmTime := newTime. 


setCompClockAlarmTime: newTime 
clockOne setClockAlarmTime: newTime. 


displayCompClockAlarmTime 
“clockOne displayClockAlarmTime. 


displayCompClockTime 
“clockOne displayClockTime. 


displayCompRadiooOnoffState 
“radioOne displayRadioonoffState. 


displayCompRadioVolumeLevel 
“radioOne displayVolumeLevel. 


displayCompRadioAmChannel 
“radioOne displayAmChannel. 


displayCompRadioFmChannel 
“radioOne displayFmChannel. 


displayCompClockRadioPosition 
“compClockRadioPosition displayPosition. 
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APPENDIX C. CLOS CODE 


CLOS CLASS DEFINITIONS 


nietLelass xy posit () 
((x :initform 0 :type integer) 
(y :initform 0 :type integer) ) ) 


(defclass time () 
((hours :initform 0 :type integer) 
(minutes :initform 0 :type integer) 
(seconds :initform 0 :type integer) )) 


(defclass radio () 
((radio location :initform (make-instance 


ey BOCsane )) 
(radio powered :initform "false") 
fate LO TON t berm "Off stype string) 


(fm station :initform 88 :type float) 
Cals de tOm nit tOrm 55) = typenfloat) 
(Mmeeeswitch = simitform “OLf" =sevpe string) 
(volume level wine LOrM sO wtype float) ) ) 


(defclass electric clock () 
((clock location :initform (make-instance 
oy eos) ) 
(clock powered :initform "false" :type string) 
(clock alarm :initform "off" :type string) 
(current time :initform (make-instance ‘time) ) 
(clock alarm time sinitform (make-instance ‘/time) ) ) 


Pichemassuclocin radio (radio electric clock) 
({clock radio powered :initform "false" :type string) 
(radio alarm time :initform (make-instance ’time) ) 
(advo alarm cinittorom “oft” stype string) )) 


(defclass composite clock radio () 
((clock one :initform (make-instance 
‘electric clock) ) 
(radio one :initform (make-instance ‘radio) ) 
(comp clk rad positon :initform (make-instance 


ye Osm es 
(comp clk rad powered :initform "false" :type 
Stnune ei a 
(onpmeadtomatarm -InatLonme Crt “stype string) 
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D. 


(comp radio alarm time :initform (make-instance 
‘time) ) ) 


xX Y POSIT CLASS METHODS 


(defmethod change xyvals ((p x_y posit) xpos ypos) 
(set£ (slot-value p 'x) xpos) 
(set£f (slot-value p ’y) ypos)) 


(defmethod display position ((p x_y posit)) 
(format t "Current XY position Ase. aly a 
(slot-value p ‘'x) 
(slot-value p ‘y))) 


TIME CLASS METHODS 


(defmethod change time ((tt time) hrs mins secs) 
(setf (slot-value tt ‘’hours) hrs) 
(setf£ (slot-value tt ’/minutes) mins) 
(setf (slot-value tt ’seconds) secs) ) 


(defmethod display time ((tt time) ) 
(format t "The time is ~a:~a:~a." 
(slot-value tt ‘’hours) 
(slot-value tt /minutes) 
(slot-value tt ’ seconds) )) 


RADIO CLASS METHODS 


(defun make-object-radio () 
(make-instance ‘’radio)) 


(defmethod change radio position ((xr radio) xpos ypos) 
(with=Silocs (eadivo local vom) mane 
(change xyvals radio location xpos ypos) 


(defmethod power radio ((r radio) ) 
(with-slots (radio powered) r 
(setf radio powered "true") )) 


(defmethod remove radio power ((r radio) ) 
(with-slots (radio powered) r 
(setf£ radio powered "false”))) 


(defmethod turn) cadio on. wadsers 
(with-slots)(zadtogon) ie 


rs 6 


RS 


: 





(Se€Ef radvegon “cnaes 


ide lLleriocwelilir aad To lOLf 9((ms radio) } 
(with-slots sacle oi) = 
(Soe erate On Ort) )) 


(defmethod increase volume ((iaracio ne) 
(with-slots (volume level) r 
(setf volume level (* volume level 2.0)))) 


(defmethod decrease volume ((r radio)) 
(with-slots (volume level) r 
(Ser volume level ~ volume level .35))))) 


(defmethod select am ((r radio) ) 
(with-slots (am_ fm __ switch) te 
(Serf am fm | switch "am"))) 


(defmethod select fm ((r radio) ) 
(with-slots (am_fm_switch) 1s 
(seer ampim switch “fm” )) ) 


(defmethod select am station ((r radio) channel) 
(with-slots (am_ station) 1g 
(setf am station channel) ) ) 


(defmethod select fm station ((r radio) channel) 
(iheiiashOtsm (£m SEACLON) r 
(Sele LNostatrton Channel) ) ) 


(defmethod display _ Trea ClO Ce Pi seat ee radio) ) 
(format t "The radio aS ae 
(slouswalue ©r ‘radio On) )) 


emicenciearaptay volume level ((r radio) } 
(format t "The radio volume level is ~A." 
(SlCr Me rs volume lecel))))) 


(defmethod display am_channel ((r radio) ) 
(format t "The am station is ~A." 
(slot-value r Pammatedia.on))))) 


(defmethod display fm channel ((r radio) ) 
(format t "The fm station is ~A." 
(slot-value r ’fm atation) )) 


(defmethod display radio_position ((r radio)) 
(with-slots (Par- Tob ome location): 
(display position | radio location) )) 
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ELECTRIC CLOCK CLASS METHODS 


(defun make-objedt-elleceritecle teeing 
(make-instanee) eleceritemolce.)) 


(defmethod change clock i post. tem (ec elecewleme Loew 
xpos ypos) 
(with-slots (clock @l@calien mec 
(change xyvals clock location xpos ypos) )) 


(defmethod powexselock (eee lecrr1 Cle leas 
(with-slots (clock pewermec mec 
(setf£f clock powered "true"))) 


(defmethod remove clock power ((ec elecerice fet oc» 
(with-slots (clock powered) ec 
(sett cleck powered. eat ea. 


(defmethod reset clock time ((ec elect lege loe. a ae= 
mins secs) 
(with-slots (current wmee 
(change time Current (Gane ees aris esee a) 


(defmethod clock alarm onwG@(eevetcerr ieee loca 
(with-slots (clock alarm see 


(sett clo¢cealamne on. 7ay) 


(defmethod clock alarmvof Gm (ce elect memeioenws 
(wath-slots (clockvalamam@ec 
(sett clock falar "ort ))) 


(defmethod set clockialarmierme ((ec electric clock) hrs 
mins secs) 
(with-slots (clock alarm time) ec 


(change time clock alarm time hrs mins secs) )) 


(defmethod display clock alarm time ((ec 
electric clock)) a 7 
(with-slots (clock alarm time) ec 
(display time clock alarm time) )) 


(defmethod Gisplay Jelock ean (eee lecuntegetoca» 
(with-slots (Current Jeane) ec 
(display time cur _ time) )) 


(defmethod display clock location {((ec electricielocia® 


(with-slots (clock location) ec 
(display position clock location) )) 


az 
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CLOCK RADIO CLASS METHODS 


(defun Makesom ject-clock radio () 
(Make -imseance = Glock radio) ) 


(defmethod change clk rad position (Ge i clock radio) 
xpos ypos) 
(with-slots (radio _ l@O@atiOn selock Mm Ocatien) cr 
(change xyvals radio location xpos ypos) 
(change xyvals clockeliecatelen xpos ypos) )) 


(defmethod power clock radLo wt ler Clock wEad1O) ) 
((set£ radio powered "true") 
(seet clock powered "“true”))) 


fieimetnod remove clock radio power ((cr clock radio) ) 
((setf radio _ powered "false") 
(seer clock powered “false ))) 


(defmethod set radio alarm time ((cr clock radio) hrs 
mins secs) 7 a 7 
(with-slots (radio alarm time) cr 
(change time radio alarm time hrs mins secs) )) 


(defmethod radio alarm on ((cr clock _ radio) ) 
(with-slots (radio _ alarm) cr 
(sett radio alarm ton oy) 


(defmethod radio alarm off ((cr clock _ seve), 
(with-slots (radio _alarm) GE 
fsetr rad om alain oe foe) 


(defmethod display radio alarm on off state ((cr 
clock radio)) a is 7 
(format t "The radio alarm is ~A." 
(rGe-valuc Cr radeo alarm) )) 


(defmethod display radio alarm_time ((cr clock_radio) ) 
(with-slots (radio alarm time) er 
(display time radio alarm time) )) 


fcomuceiod display Clock radio position ((cr 
clock radio) ) 
(with-slots (clock location) cr 
(Geselaygpositson clock locari1on) )) 


ile 


G. 


COMPOSITE CLOCK RADIO CLASS METHODS 


(defun make-object-composite clock radio () 
(make-instance ‘composite clock radio) ) 


(defmethod power comp clock radio ((ccr 
composite clock radio) ) 
(with-slots (comp _clk_rad_ powered clock one radio one) 
ccr 
(setf comp clk xad powered™ erue) 
(power _ radio radio one) 
(power clock clock > mene ye) 


(defmethod remove comp clock _radio power (eer 
composite — clock _xadio) ) 
(with-slots (comp clk rad powered clock one radio one) 
GCE 
(seC£ comp clk rad¥poweteqs falc. 
(remove _xradio power radio money 
(remove leloelk power clock > Boney) 


(defimetnod jehange® comp _ clk _rad_posit on 4( (Cer 
composite clock _radio) xpOS ypos, 
(with-slots (radio _ one erect note 
comp clk _rad_ position) Cer 
(change position comp clk rad position xpos ypos) 
(Change radio position xpOs ypos))) 


(defmethod turn comp radiogen |( (cer gaae a) ) 
composite clock radio 
(with-slots (radio one) cer 
(LurmM Tada omoneradiemoncy a. 


(defmethod Eurn  conpenad] ones ealce. 
composite clock radio) ) 
(with-slots (radio one) ccr 
(turn radio off radio one) )) 


(defmethod increase comp radio volumes (cer 
composite clock radio) ) 
(with-slots (radio one) ccr 
(increase volume radio one) ) ) 


(defmethod decrease comp radio volume ((ccr 
composite _ clock badro))) 
(with-slots (radio one) Cer 
(decrease Volume hadi some) 5s) 


(defmethod setece wan status ongsa(cer 
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composite clock radio) channel) 
(with-slots (eachomone ym ccs 
(slect_ am_station radio one channel) )) 


(defmethod select fm station ((ccr 
composite clock radio) channel) 
(with-slots (radio one) ccr 
(select fm_ station radio one channel) )) 


(defmethod select am ((ccr composite — clock radio) ) 
(with-slots (radio one) ccr 
(select am radio one))) 


(defmethod select fm ((ccr composite _ clock radio) ) 
(with-slots (radio _ one) ccr 
(select fm radio one) )) 


(defmethod reset _comp clock _ time (C( Covers 
composite © clock _ radio) “hrs mins secs) 
(with-slots (clock one) ccr 
(reset clock time clock one hrs mins secs))) 


etmethocecomp Clock alarm on ((ecr 
Ecipostre clock radio} ) 
(with-slots (clock one) ccr 
(clock alarm _on clock_one))) 


iijermethod Comp Clock alarm off ((ccr 
composite _ Clock _radio)) 
(with-slots _ (clock one) Ger 
(clock _alarm off elock one) )) 


(defmethod comp _ radio alarm on ((ccr 
composite _ clock _ radio) ) 
(with- slots (comp _ radio _alarm) ccr 
(cet Comp. radio alarm "on"))) 


faermethod secomp radr1o alarm off ((ccr 
cComposite clock radio) ) 
(with-slots (comp _ radio alco) eee 
(setf comp radio alarm "off"))) 


(defmethod set radio alarm time ((ccr 
composite clock radio) hrs mins secs) 
(with-slots (comp radio alarm time) ccr 
(change time comp radio alarm time hrs mins secs) )) 


ILS: 


(defmethod set (comp cloe) jatar mewne ( (ée@r 
composite "elocs _xadio) hrs mins secs) 
(with-slots (clock one) ccr 
(set clock alarm time clock one hrs mins secs) ) ) 


(defmethod display [compyctoci a Earnie mcm aeee 
composite _ clock radio) ) 
(with-slots (clock_one) Cer 
(display clock alarm tame clock one) )) 


(defmethod display comp clock alarm time ((ccr 
composi ecm clock _xadio) ) 
(with-slots (clock one) ecr 
(display clock alarm time clock _ one) )) 


(defmethod display comp clock time ((ccr 
composite clock radio)) © 
(with-sloes (clock lonejmec. 
(display clock time Rech youc))))) 


(defmethod display — COmMp _ bareKS SC) OD TOLL Wst ate VGlee 
COnpesiie ye ler _ radio) ) 
(with-slots (radio one) Cer 
(display _radio_on_off_ state lee(ekVe (eles), | 


(defmethod display comp radio volume level ((ccr 
COMpOsatzeu clock _ radio) ) 
(with-slots (radio one) Cer 
(display volume (level adiomoncyae 


(defmethod display comp radio am channel ((eer 
composite _ clock radio) ) 
(with-slots (cadio_ one) lene 
(display am channel radio one) )) 


(defmethod display comp radve  inmewamie  eieens 


composite clock _ radio) ) 
(display fm channel rereKeln(O) OMVEN) 
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